Recientemente he decidido permitir todos los caracteres para mi sitio web. ¿Hay algún error de seguridad común con el que deba lidiar? ¿Hay alguna forma de "inyectar" usando utf-8? ¿Es seguro permitir que los usuarios usen contraseñas con caracteres alfabéticos no ingleses? y puede php's bcrypt manejar eso?
editar: no tengo idea de lo que estoy haciendo cuando se trata de cosas como conjuntos de caracteres.
Los posibles problemas de seguridad comunes inherentes a la adición de la compatibilidad con Unicode (que no son específicos de UTF-8) provienen del mayor potencial para la suplantación visual y los problemas que surgen de los desajustes de la normalización.
Visual spoofing: digamos que tienes un foro con un usuario llamado "admin" en el que todos saben confiar. Otra persona puede registrar una cuenta de usuario llamada "аdmin" (la primera letra es la letra cirílica a ), y engañar a otros para que piensen que eran el administrador del sitio. Esto es principalmente una técnica para la ingeniería social: es poco probable que algún software confunda a los usuarios. (Este ejemplo específico podría abordarse parcialmente haciendo que el sitio agregue un formato especial o estilo cerca del nombre del administrador, haciendo que los nombres de los perfiles se vinculen a las páginas de perfiles que muestran el historial de actividades del usuario y la fecha de ingreso, etc., para que los usuarios puedan identificar a otros de maneras además de su nombre permeable visible. Este es un problema más general que no es exclusivo de la compatibilidad con Unicode: los usuarios también podrían nombrarse a sí mismos con otros nombres confusos como "< site > Support", "admin" con un espacio, "admim", etc. .)
Normalización: ciertos caracteres como "ö" se pueden representar de varias maneras. Puede ser el único carácter U + 00F6 (LETRA PEQUEÑA LATINA O CON DIAERESIS), o los dos caracteres U + 0061 U + 0308 (LETRA PEQUEÑA LETRA O + DIAERESIS COMBINANTE). La normalización es el proceso de convertir todo el texto a la forma combinada o descompuesta. Si nunca usa la normalización constantemente o siempre la usa, entonces no tendrá problemas. Sin embargo, si alguna vez lo hace, puede tener problemas de seguridad:
Por ejemplo, OS X normaliza Unicode en los nombres de archivo. Digamos que tenía un sitio web sin ningún código relacionado con la normalización ejecutándose en un servidor OS X donde cada vez que un usuario se registraba, se creaba un archivo con su nombre, y usaba una base de datos sin ninguna normalización para realizar un seguimiento de los nombres de usuario que ya estaban registrados en orden para evitar que los nombres vuelvan a registrarse. Si tuviera un usuario llamado "foö" (usando U + 00F6), alguien más podría registrar una cuenta llamada "foö" (U + 0061 U + 0308), y el sitio lo permitiría pero sobrescribiría el archivo creado por primer usuario "foö". Para resolver esto, debe hacer que su aplicación se normalice de manera consistente a lo largo de toda la aplicación, o debería verificar las colisiones cada vez que cruce un límite que se normaliza de manera diferente (cuando un usuario se registra y necesita hacer un archivo para ello). , abra el archivo en modo exclusivo para que falle si el archivo ya existe, y puede impedir que el nuevo usuario se registre).
La respuesta de AgentME describe dos clases importantes de vulnerabilidades relacionadas con Unicode: similitud visual y normalización. No los repasaré.
También hay vulnerabilidades relacionadas con UTF-8 específicamente. UTF-8 tiene algunas secuencias de bytes no válidas y algunas aplicaciones no las manejan bien, por ejemplo. pueden fallar o calcular longitudes inválidas. Las secuencias de bytes no válidas también pueden causar estragos en los analizadores. Por ejemplo, suponga que tiene un código que duplica todas las comillas simples para rellenarlas en una consulta SQL:
"Robert'); DROP TABLE Studers;--" → "select * where name = '" + "Robert''); DROP TABLE Studers;--" + "'"
(Esperemos que esto no se haga con el código de la aplicación, sino con una biblioteca de bajo nivel ... pero en el mundo real, hay mucho código que hace esto y no siempre lo hace bien). Ahora imagina que hay un código no válido. Secuencia de bytes UTF-8 después de Robert , por ejemplo %código%. La biblioteca de citas y la base de datos tienen que acordar si el "Robert0'); etc" debe duplicarse en ese caso, y en la práctica no siempre están de acuerdo y obtienes una inyección SQL.