Si confiamos en los navegadores de que cumplen con la Política del mismo origen sin errores, ¿seguiríamos necesitando los tokens CSRF?
Suponiendo que el servidor no tiene CORS habilitado: Por lo que sé, no se nos permite realizar solicitudes POST de origen cruzado, ¿por qué hay un token CSRF?
Si el servidor tiene CORS habilitado: (asumiendo tanto GET como POST, porque no veo el punto de CORSing POST pero no GET)
Podríamos OBTENER la página, leer el token y POST una solicitud correcta.
Si confiamos en los navegadores de que cumplen con la Política del mismo origen sin errores, ¿seguiríamos necesitando los tokens CSRF?
Sí, lo haremos. Debido al hecho de que hay otras solicitudes que no se incluyen en SOP como formulario enviado, cargando scripts ... etc.
Suponiendo que el servidor no tiene CORS habilitado: Por lo que sé, no podemos realizar solicitudes POST de origen cruzado, ¿por qué hay un token CSRF?
Incluso cuando CORS está deshabilitado, el navegador completará las solicitudes POST de XHR, el atacante no podrá acceder a la respuesta, pero la solicitud se completará y cumplirá con éxito el ataque CSRF.
Sin embargo, esto fallará en el caso de las solicitudes PUT , PATCH y DELETE , ya que el navegador emitirá primero una solicitud OPTIONS al punto final de la solicitud para verificar la solicitud.
Si el servidor tiene CORS habilitado: (asumiendo tanto GET como POST, porque no veo el punto de CORSing POST pero no GET) Podríamos OBTENER la página, leer el token y POST una solicitud correcta.
Esto sería una vulnerabilidad con el propio servidor. CORS no debe estar abierto a todos los hosts remotos, solo a los que posee (confianza).
Lea otras preguntas en las etiquetas csrf same-origin-policy cors