¿Por qué se requiere Access-Control-Allow-Origin para las solicitudes de dominio cruzado sin credenciales? [duplicar]

Question

¿Por qué se requiere Access-Control-Allow-Origin para las solicitudes de dominio cruzado sin credenciales? [duplicar]

#1 de rook (2 votos)

3

Entiendo CSRF y por qué no se pueden permitir las solicitudes AJAX entre dominios con cookies u otras credenciales sin un encabezado Access-Control-Allow-Credentials les permite explícitamente, de lo contrario, podría hacer cosas como atraer a las personas a un sitio que secuestra sus cookies de Facebook para publicar algo en Facebook en su nombre.

Lo que no entiendo es por qué incluso las solicitudes AJAX entre dominios sin credenciales no están permitidas sin un encabezado Access-Control-Allow-Origin . Sin credenciales involucradas, CSRF parece imposible y, por lo tanto, los únicos argumentos que conozco para la Política del mismo origen parecen no aplicarse. ¿A qué vulnerabilidad estarían expuestos los sitios o los usuarios si no se aplicara esta restricción?

http csrf same-origin-policy

pregunta Mark Amery 21.08.2013 - 17:54

fuente

1 respuesta

Lea otras preguntas en las etiquetas http csrf same-origin-policy

SQLMap: ¿Cómo probar los nombres de campo generados por JavaScript? Exponer el servicio web de forma segura

score 2 · Accepted Answer

Has tropezado con una irregularidad causada por un intento de hacer estándares seguros. En resumen, los exploits CSRF no pueden usar un CORS XHR debido al requst de verificación previa , atacantes Se ven obligados a utilizar otras técnicas. En un XHR, puedes leer la respuesta. Sin embargo, en un ataque CSRF, al atacante no le importa leer la respuesta. Un exploit CSRF basado en GET puede ser simplemente una etiqueta <img> . Un exploit CSRF basado en POST es el siguiente:

<form id="csrf_exploit" action="https://victim_site/passsword_change" method="POST">
  <input name="new_password" value="hacked">
  <input name="repeat_password" value="hacked">
  <input type=submit>
</form>
<script>
  document.getElementById("csrf_exploit").submit();
</script>

En el exploit anterior, el navegador completo se redirige cuando se envía la solicitud POST. A menudo, una hazaña como esta se coloca dentro de un iframe para ocultar esta redirección a la víctima. El navegador presenta la respuesta y el atacante obtiene los beneficios del efecto secundario producido por la solicitud. En este caso, el efecto secundario es cambiar la contraseña del usuario.