tag - Seguridad de PHP: ¿cómo puede ser mal utilizada la codificación?
title tags html (2)
De esta excelente pregunta " UTF-8 hasta el final ", leí sobre esto:
Desafortunadamente, debe verificar que cada cadena enviada sea UTF-8 válida antes de intentar almacenarla o utilizarla en cualquier lugar. PHP mb_check_encoding () hace el truco, pero tienes que usarlo religiosamente. Realmente no hay forma de evitar esto, ya que los clientes malintencionados pueden enviar datos en cualquier codificación que deseen , y no he encontrado un truco para que PHP haga esto por usted de manera confiable.
Ahora, todavía estoy aprendiendo las peculiaridades de la codificación, y me gustaría saber exactamente qué pueden hacer los clientes malintencionados para abusar de la codificación. ¿Qué se puede lograr? ¿Alguien puede dar un ejemplo? Digamos que guardo la entrada del usuario en una base de datos MySQL, o la envío por correo electrónico, ¿cómo puede un usuario crear daño si no uso la funcionalidad mb_check_encoding ?
¿Cómo puede un usuario crear daño si no uso la funcionalidad mb_check_encoding?
Esto es sobre codificaciones demasiado largas .
Debido a un inconveniente desafortunado del diseño UTF-8, es posible crear secuencias de bytes que, si se analizan con un decodificador de empaquetamiento de bits ingenuo, darían lugar al mismo carácter que a una secuencia más corta de bytes, incluido un único carácter ASCII.
Por ejemplo, el carácter < generalmente se representa como byte 0x3C, pero también podría representarse usando la secuencia UTF-8 0xC0 0xBC (o incluso secuencias más redundantes de 3 o 4 bytes).
Si toma esta entrada y la maneja en una herramienta basada en byte ajeno a Unicode, entonces cualquier paso de procesamiento de caracteres que se utilice en esa herramienta puede ser evadido. El ejemplo canónico sería enviar 0x80 0xBC a PHP, que tiene cadenas de bytes nativas. El uso típico de htmlspecialchars para codificar en HTML el carácter < fallaría aquí porque la secuencia de bytes esperada 0x3C no está presente. Por lo tanto, la salida de la secuencia de comandos aún incluiría el codificado en exceso < , y cualquier navegador que lea esa salida podría leer la secuencia 0x80 0xBC 0x73 0x63 0x72 0x69 0x70 0x74 como <script y ¡listo! XSS.
Los excesos de duración han sido prohibidos desde hace mucho tiempo y los navegadores modernos ya no los permiten. Pero este fue un problema genuino para IE y Opera durante mucho tiempo, y no hay garantía de que cada navegador lo haga bien en el futuro. Y, por supuesto, esto es solo un ejemplo: en cualquier lugar donde una herramienta orientada a bytes procese cadenas Unicode, posiblemente tenga problemas similares. El mejor enfoque, por lo tanto, es eliminar todos los prolongados en la fase de entrada más temprana.
Parece que este es un ataque complicado. La comprobación de los documentos para mb_check_encoding da nota a un "Ataque de codificación no válido". Al buscar en Google "Invalid Encoding Attack" aparece algunos resultados interesantes que intentaré explicar.
Cuando este tipo de datos se envían al servidor, se realizará una decodificación para interpretar los caracteres que se envían. Ahora el servidor realizará algunas comprobaciones de seguridad para buscar la versión codificada de algunos caracteres especiales que podrían ser potencialmente dañinos.
Cuando se envía una codificación no válida al servidor, el servidor sigue ejecutando su algoritmo de decodificación y evaluará la codificación no válida. Aquí es donde ocurre el problema porque es posible que las comprobaciones de seguridad no busquen variantes no válidas que aún podrían producir caracteres dañinos cuando se ejecutan a través del algoritmo de decodificación.
Ejemplo de un ataque que solicita una lista completa de directorios en un sistema unix:
http://host/cgi-bin/bad.cgi?foo=..%c0%9v../bin/ls%20-al|
Aquí hay algunos enlaces si desea una explicación técnica más detallada de lo que está sucediendo en los algoritmos:
http://www.cgisecurity.com/owasp/html/ch11s03.html#id2862815