P.S. db es a través de las mejores prácticas DOP así que no hay riesgo de inyección SQL¿Qué restricciones debo imponer a los nombres de usuario
Gracias
OK, así que supongamos que está haciendo todas las tareas de codificación de cadenas correctas. No tiene inyecciones de SQL, inyecciones de HTML ni lugares donde no esté codificando URL algo que debería. Así que no tenemos que preocuparnos de que caracteres como "< &% \ sean mágicos en algunos contextos. Y está usando UTF-8 para todo, así que todo Unicode está en juego. ¿Qué otras razones existen para limitar los nombres de usuario?
para empezar, todos los caracteres de control, a la cordura. no hay ninguna razón para tener caracteres u + 0000 a u + 001F o u + 007F a u + 009F en un nombre de usuario.
a continuación, negar o normalizar inesperada espacios en blanco. Es posible que desee permitir un espacio en un nombre de usuario, pero es casi seguro que no desea permitir espacios iniciales, espacios finales o más de un espacio en una fila. Pueden representar lo mismo en HTML, pero probablemente sean error de usuario que confundirá.
Si tiene la intención de permitir que el nombre de usuario se use para iniciar sesión mediante HTTP Basic Authentication, debe rechazar el carácter :, porque el esquema de autenticación básica codifica un par de 'nombre de usuario: contraseña' sin escape si hay dos puntos en el nombre de usuario o contraseña.Por lo tanto, al menos uno de los nombres de usuario y la contraseña deben tener los dos puntos excluidos, y es mejor que ese sea el nombre de usuario porque restringir la elección de las contraseñas es mucho peor que los nombres de usuario.
Para la Autenticación básica, es posible que también desee deshabilitar todos los caracteres que no sean ASCII, ya que son manejados de forma diferente por diferentes navegadores. IE los codifica utilizando la página de códigos del sistema; Firefox los codifica usando ISO-8859-1; Opera los codifica usando UTF-8. Los usuarios deben al menos ser advertidos antes de elegir nombres que no sean ASCII si HTTP Auth va a estar disponible, ya que usarlos realmente será poco confiable.
Considere otras secuencias de control Unicode, cosas como las anulaciones bidi y otros caracteres enumerados allí no son aptos para el uso en el marcado. Probablemente termines poniéndolos en el marcado y no quieres que alguien con un RLO en su nombre vuelva una carga del texto en tu página.
Además, si permite que Unicode haga la normalización en las cadenas que obtiene. De lo contrario, alguien puede tener un nombre de usuario con un carácter de diéresis ö, y preguntarse por qué no pueden iniciar sesión en una Mac, que de forma predeterminada usaría un carácter o por separado, seguido de la combinación de umlaut. Es normal normalizar el formulario compuesto NFC en la web. Es posible que también desee hacer descomposiciones de compatibilidad utilizando el formulario NFKC; esto permitiría a un usuario Chris iniciar sesión desde un teclado japonés en modo romaji de ancho completo escribiendo Chris. Estos son problemas generales que es bueno resolver para todas las entradas de su webapp, pero para los identificadores como los nombres de usuario puede ser más crítico para hacerlo bien.
Finalmente, asegúrese de que la longitud es correcta para caber en la base de datos sin un truncado silencioso cambiando el nombre, especialmente si está almacenando como bytes UTF-8 que no quiere que sean recortados a mitad de una secuencia de bytes. Los truncamientos de nombre de usuario también pueden ser un problema de seguridad en general.
Si está utilizando nombres de usuario como un medio único de identificación, tiene mucho más de qué preocuparse: el problema ya mencionado de parecidos como Сhris (con un cirílico Es С). Hay muchos de estos para que pueda manejarlos razonablemente; restringir a ASCII o tener un medio adicional para identificar a los usuarios. (O no me importa, como SO no; cuando puedo llamarme a mí mismo Chris de todos modos no tengo necesidad de llamarme a mí mismo С -hris.)
Gracias por la publicación épica :) Confirmó mi suspensión de que las restricciones tienen un motivo válido. – Chris
nunca he visto el punto en la adición de restricciones a los nombres de usuario. Si su código es resistente a los ataques de inyección sql, deje que coloque lo que quiera.
La única restricción es que me gustaría añadir una longitud máxima de un modo que puede ser almacenado en una tabla DB
dejarles usar cualquier carácter Unicode en su nombre de usuario. Agregar restricciones a los caracteres permitidos probablemente solo molestará a las personas que usan un lenguaje no ascii.
¿Debo dejar que los usuarios se registren con el nombre de usuario admin por ejemplo? :) exactamente el punto detrás de esta pregunta: D – Chris
por qué no. solo porque el nombre de usuario es "admin" no los convierte en administradores. Stackoverflow, por ejemplo, tiene 2 usuarios llamados "admin" y 3 llamados "Admin". Si tiene algunos nombres de usuario que no desea que se usen, no cree una restricción de código, solo cree los usuarios y ya está. es una solución rápida y simple – Glen
Es más para evitar confusiones/errores. No se debe engañar a los usuarios para que piensen que un administrador no administrador es un administrador, o pueden dirigirle preguntas inapropiadas como restablecer contraseñas, etc. La ingeniería social es parte de la seguridad general, solo mis 2 centavos. – Chris
Depende de muchas cosas, por ejemplo, si los usuarios van a tener su propia URL, debe tener cuidado de que alguien que crea el nombre de usuario "% 41llan" no entre en conflicto con el usuario llamado "Allan", mientras que permitir barra inclinada puede causar problemas. Cuidado con ese tipo de restricciones.
buen punto con "% 41llan". Aunque los usuarios no necesitan sus propias URL, me pregunto ¿cómo lo arreglas? – Chris
% La URL de 41llan se codificará correctamente en% 2541llan. Es solo otro problema de escape, al igual que la inyección SQL o HTML. – bobince
Depende de cómo elija tratarlo. Estoy trabajando en un sitio donde no quería URLs "feas", así que simplemente eliminé personajes así.Eso abre el problema de dos usuarios con la misma URL, por lo que debe verificar que los nuevos usuarios no entren en conflicto con los existentes. – Artelius
La protección de inyección SQL es imprescindible, pero probablemente debería estar en su código, no en restricciones de nombre de usuario. Ciertos personajes definitivamente deben ser escapados, como \,%, etc.
Será en el tipo de sitio que está ejecutando, pero creo que algunas restricciones de palabras obscenas haría que su sitio se vea más profesional sin importar nada. Si alguien ve que las personas pueden usar "EXPLETIVE" dado que son un nombre de usuario, su sitio parecerá infantil. Es como permitir a los adolescentes correr rampid en tu librería en mi humilde opinión. Probablemente no necesites ser mucho más quisquilloso que eso, aunque depende completamente de ti.
Esto es un poco fuera de tema, pero como otra pieza de consejo de usuario, una gran característica de cualquier sitio web es permitirles a los usuarios cambiar su nombre de usuario a lo largo del tiempo. Simplemente puede tener un número como clave principal, y permitirles hacer esto puede ahorrar muchos lloriqueos y que las personas creen nuevas cuentas porque querían cambiar su nombre de usuario. : D
cualquier filtro automático de palabras incorrectas está condenado al fracaso. En realidad, puedes crear el problema que intentas evitar ya que las personas lo consideran un juego para eludir el filtro. Como regla general, las listas negras nunca funcionan. – rmeador
Tengo que admitir que las malas palabras fueron una de las cosas que busqué. La audiencia no va a ser grande, pero estoy tratando de mantenerla limpia, pero sin ser demasiado entusiasta. – Chris
Una solución para esto sería permitir el registro, pero márquelo para que lo revise un moderador. Esto permitiría que un usuario registre "scunthorpe" o el "intercambio de expertos" no deseado, pero aún así le permitirá detectar nombres poco fiables. De hecho, aún más fácil sería hacer una red de arrastre periódica (diaria) a través de los nombres de usuario en la base de datos y detectar los que no te gusten. – Glen
recuerde que también debe preocuparse por las secuencias de comandos y las inyecciones de HTML , no solo inyecciones de SQL. Pero si siempre está codificando el nombre de usuario antes de mostrarlo, como debería ser, entonces eso no es problema. – rmeador