2011-08-29 18 views
21

He tenido problemas con XSS. Específicamente, hice que un individuo inyectara una alerta JS que mostrara que mi entrada tenía vulnerabilidades. Investigué sobre XSS y encontré ejemplos, pero por alguna razón no puedo hacer que funcionen.¿Ejemplos de XSS que puedo usar para probar la entrada de mi página?

¿Puedo obtener ejemplo (s) de XSS que puedo tirar en mi entrada y de salida cuando se de vuelta al usuario ver algún tipo de cambio como una alerta para saber que es vulnerable?

estoy usando PHP y voy a poner en práctica htmlspecialchars() pero primero estoy tratando de reproducir estas vulnerabilidades.

Gracias!

+4

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

+0

¿Cuál es el punto de prueba de las vulnerabilidades XSS ** antes de que ** implemente 'htmlspecialchars()' (o 'htmlentities()')? – Mike

+0

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

Respuesta

14

Se puede usar esta complemento de Firefox:

XSS-me es la herramienta Exploit-Me utilizado para la prueba de Cross-Site se refleja Scripting (XSS). Actualmente NO prueba para XSS almacenado.

La herramienta funciona mediante la presentación de los formularios HTML y sustituyendo el valor forma con las secuencias que son representativos de un ataque XSS. Si el página HTML resultante establece un valor específico JavaScript (document.vulnerable = true) entonces la herramienta marca la página como vulnerable a la cadena XSS dado. La herramienta no intenta comprometer la seguridad del sistema dado. Busca posibles puntos de entrada para un ataque contra el sistema. No hay escaneo de puertos, paquete olfateo, piratería de contraseñas o ataques de firewall realizados por la herramienta .

Puede considerar que el trabajo realizado por la herramienta es el mismo que el de los comprobadores de QA para el sitio que ingresa manualmente todas estas cadenas en los campos del formulario.

+1

¡Esta herramienta es increíble, lo recomiendo! Atornillar reinventando la rueda –

+0

No es compatible con la versión 5.0. ¿Alguien lo ha usado en 5.0 con éxito? – KRB

4

Por ejemplo:

<script>alert("XSS")</script> 
"><b>Bold</b> 
'><u>Underlined</u> 
1

Ad-hoc prueba está bien, sin embargo también recomiendo probar una herramienta de escaneo de vulnerabilidades de aplicaciones web para asegurarse de que no se ha perdido nada.

Acunetix es bastante bueno y tiene una versión de prueba gratuita de su aplicación:

http://www.acunetix.com/websitesecurity/xss.htm

(Nota no tengo ninguna afiliación con esta empresa, sin embargo, he utilizado el producto para probar mis propias aplicaciones).

+0

Desafortunadamente, las secuencias de comandos entre sitios son algo que los escáneres automáticos son realmente terribles de encontrar. Echan de menos la mayoría de las configuraciones vulnerables en la naturaleza y solo activan el código abierto más simple. – Cheekysoft

3

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>

Cuestiones relacionadas