¿Se ha reflejado XSS a través del valor de cookie?

Navega tus respuestas
5

Siempre he considerado el XSS reflejado como un ataque que tendría lugar a través de una URL. Entonces, por ejemplo, tendría una URL como la siguiente: 

http://someSite.com?message=welcome!<script>alert(1);</script>

y el mensaje se escribiría en la página. Para ejecutar el ataque necesitarías engañar a alguien para que haga clic en ese enlace.

Hace poco estuve buscando en un sitio web con BurpSuite, marcó una vulnerabilidad reflejada en el script de sitios cruzados y el vector de ataque fue un valor de cookie. Si bien podría cambiar el valor de la cookie para que muestre javascript en la página, no entiendo cómo podría usarse para atacar a otro usuario.

En mi primer ejemplo, un usuario tendría que hacer clic en un enlace para ejecutar el ataque. ¿Cómo ejecutarías un ataque con la segunda vulnerabilidad?

    
pregunta Abe Miessler 16.10.2014 - 19:48
fuente

3 respuestas

2

Debido a la política de cookies del mismo origen , una especie de "pollo" O se crea la situación del huevo. Para que el atacante pueda hacer viable este vector XSS, necesitarían otra falla para establecer el valor de la cookie.

Una posible ruta de explotación está utilizando una vulnerabilidad XSS en un subdominio para aprovechar la siguiente propiedad de las cookies: 

 www.foo.bar.example.com may set a cookie to be sent to *.bar.example.com or *.example.com, but not to *.something.else.example.com or *.com

Otra ruta de vulnerabilidad sería utilizar la división de respuestas HTTP en una página que está realizando una redirección. En esta situación, la división de la respuesta HTTP no se puede usar para controlar el cuerpo HTTP, que se requiere para XSS, en lugar de eso, el atacante puede inyectar un encabezado HTTP set-cookie para explotar una vulnerabilidad XSS basada en cookies en otra página.

En muchos casos, este XSS basado en cookies no es explotable. Burp debería haber marcado este problema como amarillo, lo que refleja una probabilidad de explotación media / baja.

    
respondido por el rook 16.10.2014 - 20:06
fuente
0

Las cookies establecidas a través de HTTP se presentan a través de HTTPS.

Si un atacante tiene el control total del tráfico de la red de la víctima, puede establecer una cookie a través de HTTP, y esto provocará un ataque XSS contra el sitio HTTPS. Creo que HSTS detendría esto, aunque no me he confirmado.

    
respondido por el paj28 16.10.2014 - 20:15
fuente
0

Una vez que la inyección está presente, no es necesario 'hacer clic en el enlace'. En el ejemplo proporcionado, si se procesa HTML + JavaScript, entonces el código de alerta () se ejecutará automáticamente, sin la interacción del usuario.

Esto funciona en ambos ejemplos, independientemente de dónde se encuentre el XSS en la sesión HTTP. Todo lo que se necesita es que el XSS se redirija a un lugar adecuado dentro del documento de destino.

Una vez que se explota ese agujero, pueden pasar muchas cosas. También recuerde que XSS puede ser persistente en la base de datos del sistema remoto. El navegador siempre es víctima de un ataque XSS, pero una base de datos comprometida (que contiene XSS persistente), también es una víctima desde la perspectiva del administrador del sistema.

    
respondido por el W1T3H4T 16.10.2014 - 22:05
fuente

Lea otras preguntas en las etiquetas

Pasos después de ser golpeado con malware o vulnerabilidades del navegador en Xubuntu ¿Existe una razón importante para eliminar y eliminar las contraseñas cuando la reutilización de la contraseña no es un problema?