Digamos que estamos configurando un formulario de registro para algún sitio web. Sé que si los campos de entrada no están limpios, puede ocurrir la inyección de SQL. Pero digamos que todos los campos están correctamente desinfectados.
¿Hay alguna ventaja de tener nombres de usuario solo alfanuméricos? ¿O es tan bueno permitir cualquier símbolo?
Si permites cualquier secuencia de bytes como nombre de usuario, obtendrás muchos problemas posibles que los usuarios pueden abusar y otros problemas:
Para Unicode, la misma secuencia de caracteres puede representarse como diferentes secuencias de bytes. Deberá realizar la normalización de Unicode para obtener al menos algo de seguridad contra las personas que pueden registrar otra representación de secuencia de bytes para algún nombre de usuario.
Los usuarios pueden elegir personajes de apariencia similar (por ejemplo, usar dos espacios en lugar de uno, etc.) para engañar a las personas y hacerles creer que es otra cuenta.
Los usuarios podrían incluir el carácter / dentro de su nombre y cambiar los enlaces a las páginas relacionadas con su cuenta (por ejemplo, asigna las URL de la cuenta a http://example.com/user/username , y su código se divide por / ).
La mayoría de los sitios tienen el enfoque de asignar dos valores a un usuario: primero, una "identificación técnica", que es alfanumérica, y un segundo "nombre completo", que puede contener espacios y otros símbolos. El ID alfanumérico debe ser único, y el "nombre completo" puede contener duplicados en su sitio.
Si le preocupa que un campo de texto sea objeto de abuso para realizar una inyección de SQL, el saneamiento de entrada no es la solución correcta que debe buscar.
Si el campo de texto era de forma completamente libre, entonces todos los caracteres que podrían usarse para la inyección de SQL serían una entrada válida. Si intenta evitar la inyección de SQL mediante la desinfección de las entradas, termina rechazando las entradas válidas. En otras palabras, es posible que haya evitado la inyección de SQL, pero lo hizo introduciendo un error adicional y no solucionando uno. Desde el punto de vista del usuario, hay al menos tantos casos de entrada válida que no funcionan como antes, tal vez incluso más casos que antes.
La solución adecuada para evitar la inyección de SQL es utilizar expresiones de escape o parametrizadas (que evitan la inyección en una capa de la pila de protocolos al mover la responsabilidad a una capa inferior).
Mientras se escape correctamente en todos los lugares, no hay ninguna razón técnica por la que no sea posible permitir que el campo de nombre de usuario sea un campo de texto de forma libre.
Hay una pregunta diferente sobre qué caracteres permitir en los nombres de usuario. Aunque técnicamente es posible admitir nombres de usuario de forma libre, no es necesariamente una buena idea. Hay argumentos sólidos para limitar el conjunto de caracteres permitidos en los nombres de usuario, pero esos argumentos no tienen nada que ver con la inyección de SQL.
Limitar los nombres de usuario a solo caracteres ASCII es útil si alguna vez necesita comunicarse a través de canales en los que no está seguro acerca de la codificación.
Limitar los nombres de usuario a los caracteres que se encuentran en la misma ubicación en diferentes distribuciones de teclado es útil si está trabajando en un entorno internacional. Pero no impondría tales limitaciones en el software, porque el conjunto de diseños de teclado utilizados por cada usuario difiere.
La prevención de nombres de usuarios que sean visualmente idénticos puede ser una buena idea en sistemas donde es importante poder reconocer un nombre de usuario. Esto significa que no hay caracteres no imprimibles. Y si dos caracteres se ven iguales, solo se permite uno (esto rara vez es un problema si se mantiene solo con caracteres ASCII). Y no se pueden permitir espacios al inicio y al final del nombre de usuario, ni tampoco se pueden permitir dos espacios uno al lado del otro.
Y recuerde que restringir qué nombres de usuario están permitidos no es un sustituto para generar su SQL de forma segura.
Para los campos nombres de usuario no es necesario usar solo alfanuméricos , pero debe tener cuidado al incluir en la lista negra algunos caracteres especiales como 'y "en las validaciones de entrada.
Para los campos Contraseña es necesario usar alfanumérico y algunos caracteres especiales como @ y # para hacer que nuestra contraseña sea tan segura.
Por ejemplo, debería estar en Abc @ 123 # y no debería estar en abcd, porque si usas una contraseña débil es posible que un atacante secuestre usando ataque de fuerza bruta
El nombre de usuario puede ser: abc123, pero se debe validar.
Lea otras preguntas en las etiquetas user-names registration