¿Existe una biblioteca probada con funciones para prevenir ataques XSS? Muchas personas no se dan cuenta de que htmlspecialchars no es suficiente para prevenir los ataques XSS. Hay varios contextos que necesitan su propio escape (propiedades html, Javascript, ¿más?). ¿Existe una biblioteca probada que me proporcione funciones para escapar en todos estos contextos?
Sí, hay varias bibliotecas de este tipo. La elección de la biblioteca depende de qué lenguaje / marco de programación web está utilizando.
Primero, debes comenzar por leer sobre XSS. Recomiendo el siguiente documento:
Luego, una vez que se haya familiarizado con eso, puedo señalarle algunas bibliotecas que proporcionan funciones de escape bien probadas:
Sin embargo, permítame advertirle que usar estas funciones correctamente requiere conocimiento del desarrollador, y es potencialmente propenso a errores. Hay muchos contextos de análisis diferentes en los que se pueden inyectar datos dinámicos en contenido HTML, CSS o Javascript; cada contexto de análisis puede requerir que se aplique una función de escape diferente (o secuencia de funciones de escape). El desarrollador debe asegurarse de aplicar la (s) función (es) de escape correcta (s) cada vez que inyecte datos dinámicos en dicho contenido. Esto requiere conocer los riesgos de XSS y cómo defenderse contra ellos.
Este enfoque (que escapa manualmente los datos donde se usa) también es propenso a errores. Es fácil olvidarse de aplicar una función de escape. Si tiene 100 lugares donde incluye datos dinámicos en el documento, sería fácil de recordar en 99 lugares y, sin darse cuenta, olvidarse de escapar en uno de ellos. Somos solo humanos, y ese tipo de errores son fáciles de cometer. Las bibliotecas de funciones de escape no ayudan a los desarrolladores a evitar este problema.
Una mejor solución es usar un marco de programación web que ayude a los desarrolladores a evitar este problema. El estado del arte es la auto-desinfección sensible al contexto. Esto funciona particularmente bien con marcos que proporcionan un sistema de plantillas HTML. En tal sistema, el motor de plantillas es responsable de escapar automáticamente todos los datos no estáticos que se interpolan en la plantilla. Debido a que el motor de plantilla puede identificar el contexto de análisis donde se insertan dinámicamente los datos, el motor de plantilla puede seleccionar y aplicar automáticamente la función de escape adecuada.
El problema principal con la auto-desinfección sensible al contexto es que solo unos pocos marcos de programación web lo soportan actualmente. Algunos marcos web que admiten auto-saneamiento sensible al contexto: Google Ctemplate (Plantillas de cierre ), GWT, Google Clearsilver.
Para más información sobre este tema, puedo recomendar encarecidamente el siguiente trabajo de investigación:
En lugar de usar escapadas sensibles al contexto (probablemente hay varias bibliotecas de PHP que intentan ir de esta manera) recomendaría usar un analizador HTML-XSS completo que creará un árbol de documentos y permitirá solo los elementos seleccionados de la lista blanca, atributos etc.
Los proyectos que acompañan este enfoque son HTMLPurifier y Wibble . Por ejemplo, Wibble:
No hay lugar para que pase un código malicioso proveniente de una sintaxis HTML casi válida. Si hay algún problema con el HTML, lo más probable es que sea su lista blanca incompleta (o algún extraño vector de ataque html / tidy, pero lo dudo).
Actualización: Si no necesita un analizador HTML completo, otra opción es utilizar el motor de plantillas seguro por defecto. El único proyecto de PHP con escape de contexto que conozco es Nette Latte motor de plantillas, aunque no lo usé. Otros motores también tienen diferentes técnicas de escape, pero debe especificar el contexto por sí mismo (y si omite el contexto una vez, estará abierto a los ataques XSS). Los ejemplos son Twig o Smarty . Puede simplemente sacar el código de escape de aquellos para usarlo fuera del motor de plantillas.
La mejor solución contra XSS es hacer que los programadores entiendan cómo los datos pueden ser peligrosos y utilizar escapadas sensibles al contexto cuando generan datos. Siempre. Hace que los programadores piensen más sobre lo que están haciendo y le ofrece programas más sólidos. No veo ningún problema con ese enfoque :-)
Hay dos cosas a tener en cuenta:
HTML Purifier es bueno, pero no conoce el contexto en el que se usa. El siguiente código es vulnerable:
<input type="text" name="test" value="<?php echo $hp->purify($_GET['foo']); ?>" />
Prueba de concepto: /?foo=test%22%20onload%3D%22alert(%27XSS%27)%3B
Escape consciente del contexto es generalmente algo que solo adquieres a través de tu motor de plantillas. El caso más general:
htmlentities() con ENT_QUOTES ; especifique el conjunto de caracteres (por ejemplo, 'UTF-8' ). Si le preocupa el rendimiento de la ejecución de los datos proporcionados por el usuario a través de HTMLPurifier en cada solicitud, proporcione la biblioteca Stauros XSS un remolino. (El archivo Léame dice que aún es experimental, pero todavía tengo que encontrar una manera de evitarlo).