Es muy bueno para utilizar algunas de las herramientas automatizadas, sin embargo no se ganará alguna idea o experiencia de aquellos.
El punto de ataque XSS es ejecutar javascript en una ventana del navegador, que no es suministrado por el sitio. Entonces, primero debe echar un vistazo en qué contexto los datos suministrados por el usuario están impresos en el sitio web; que podría ser dentro de <script></script>
bloque de código, podría ser dentro de <style></style>
bloque, que podría ser utilizado como un atributo de un elemento <input type="text" value="USER DATA" />
o por ejemplo en un <textarea>
.Dependiendo de eso, verá qué sintaxis usará para escapar del contexto (o usarlo); por ejemplo, si está dentro de las etiquetas <script>
, podría ser suficiente cerrar la paréntesis de una función y finalizar la línea con punto y coma, por lo que la inyección final se verá como ); alert(555);
. Si los datos suministrados se utilizan como un atributo html, la inyección puede parecerse a " onclick="alert(1)"
, lo que provocará la ejecución de js si hace clic en el elemento (esta área es rica para jugar, especialmente con html5). El punto es que el contexto de xss es tan importante como cualquier función de filtro/sanatización que pueda existir, y a menudo puede haber pequeños matices que la herramienta automatizada no captará. Como puede ver arriba, incluso sin comillas y etiquetas html, en un número limitado de circunstancias, es posible que pueda eludir los filtros y ejecutar js.
También debe considerarse la codificación del navegador, por ejemplo, puede omitir filtros si el navegador de destino tiene codificación utf7 (y codifica su inyección de esa manera). La evasión de filtros es una historia completamente diferente, sin embargo, las funciones actuales de PHP son bastante antibalas, si se usan correctamente.
También aquí se encuentra una lista suficientemente largo de XSS vectors
Como última cosa, aquí es un ejemplo real de una cadena XSS que se encontró en un sitio, y le garantizo que ni un solo escáner hubiera encontraron que (había filtros y listas negras de palabras diferentes, la página que se permite insertar el formato básico del hTML para personalizar su página de perfil):
<a href="Boom"><font color=a"onmouseover=alert(document.cookie);"> XSS-Try ME</span></font>
vulnerabilidades de inyección de código como XSS o inyección SQL son siempre el resultado de un uso inadecuado o falta de datos de escape. En PHP * debes * usar 'htmlspecialchars()' en * todo * que salgas a la página que no está destinada a ser marcada. Para guardar algunos tipos, puede usar una función 'contenedora' ($ s) {return htmlspecialchars (s); } 'y use' h() 'en todas partes. – Tomalak
¿Cuál es el punto de prueba de las vulnerabilidades XSS ** antes de que ** implemente 'htmlspecialchars()' (o 'htmlentities()')? – Mike
Además, siempre piense en el "nivel de código" en el que se encuentra: Por ejemplo: cuando escribe datos generados por el usuario en un comentario HTML, realmente no tiene que 'htmlspecialchars()', pero debe * recordar * elimine cualquier aparición de '->' de esos datos o tiene una posible vulnerabilidad XSS allí. – Tomalak