¿Por qué puedo leer la respuesta a este ataque CSRF?

Question

¿Por qué puedo leer la respuesta a este ataque CSRF?

#1 de D.W. (5 votos)
#2 de rook (3 votos)
#3 de tylerl (2 votos)

2

Tengo un sitio web www.foo.com:8002 que he resuelto en 127.0.0.1:8002 en mi archivo de hosts. Tengo otro (el sitio principal) ejecutándose en localhost: 80

En www.foo.com:8002, la página se ve así

<form name="myform" action="http://localhost/bar" method="post">
  <input type="hidden" name="some" value="value" />
</form>
<script> document.myform.submit() </script>

Esperé que la solicitud pasara y que el navegador (Chrome) no leyera la respuesta ya que viola la misma política de origen. Sin embargo, resulta que el navegador recibe la respuesta y muestra el contenido perfectamente bien. ¿Cómo es esto posible?

web-browser csrf same-origin-policy

pregunta Jarrod Everett 28.08.2012 - 00:09

fuente

3 respuestas

3

Ese es el punto de CSRF, su navegador realiza la solicitud como si fuera iniciada por un usuario. En una situación de ataque CSRF real, el GET o POST estará dentro en un iframe invisible para que la víctima no se dé cuenta de que ha sido comprometida.

En este caso, el JavaScript o el ActionScript del atacante que se ejecuta en el navegador de la víctima no puede leer la respuesta de la solicitud forjada entre sitios.

Dicho esto, debe leer parte 2 del manual de seguridad del navegador y considerar seriamente la posibilidad de retirar una copia de La web enredada .

respondido por el rook 28.08.2012 - 02:20

fuente

2

El comando document.myform.submit() activa una acción del navegador y un evento de navegación. Esto significa que no está restringido por la política de origen mismo . Si, por el contrario, ha intentado enviar la solicitud como XHR e interpretar el resultado utilizando el mismo código JS en ejecución, puede Se han encontrado con dificultades.

respondido por el tylerl 28.08.2012 - 04:48

fuente

Lea otras preguntas en las etiquetas web-browser csrf same-origin-policy

¿Hay algún estándar de seguridad de aplicaciones web? Cómo obtener una lista exhaustiva de cifrados para TLS 1.0, TLS 1.1 y TLS 1.2

score 5 · Accepted Answer

¡Ahh! Creo que puedo explicar.

foo.com puede navegar por el navegador a cualquier página o dominio. Por lo tanto, foo.com puede enviar un formulario que publique en localhost , aunque sea un dominio diferente. No hay problema.
Después de navegar a una nueva página, el navegador mostrará el contenido de la nueva página al usuario. Por ejemplo, después de enviar el formulario a localhost , el navegador mostrará la respuesta de localhost al usuario.

Esto no es una violación de la política del mismo origen, porque la respuesta se muestra al usuario , no a foo.com . El usuario es de confianza y no está restringido por la política del mismo origen. La política del mismo origen solo restringe los sitios web, no el usuario.
En ningún momento, foo.com puede leer la respuesta de localhost . El navegador mostrará la respuesta de localhost en la pantalla, pero foo.com no puede leerla. Eso es lo que prohíbe la política del mismo origen.

En resumen: la política del mismo origen no impide que un sitio navegue por el navegador a otro. No evita que un sitio active una solicitud a otro sitio. Sin embargo, sí evita que el primer sitio lea la respuesta a esa solicitud en el segundo sitio.