He hecho una pregunta con respecto a una implementación de ASP.NET WebAPI de protección CSRF:
Aunque hay una respuesta que dice que, con las políticas CORS predeterminadas, ese tipo de validación de token XSRF con llamadas AJAX es inútil. ¿Es esto cierto? Y si es así, ¿por qué?
Sí, es muy probable que necesite realizar algunas comprobaciones para garantizar la autenticidad de la solicitud.
Básicamente, ¿qué es posible desde un sitio web de un tercero?
GET o POST . No es posible establecer encabezados personalizados a través de formularios html. No es posible utilizar otros métodos como PUT o DELETE . Consulte esta pregunta o RFC . Access-Control-Allow-Origin y Access-Control-Allow-Methods enviado por su servidor) y configure los encabezados personalizados. Tenga en cuenta que las solicitudes GET y POST no son posibles con ajax sin esos encabezados mientras estén en formato html. Los diferentes escenarios son los siguientes:
Usted usa el objeto javascript XMLHttpRequest básico para hacer la solicitud GET o POST . ¡Eres vulnerable ya que esto es posible hacer la solicitud equivalente desde un sitio cruzado usando el formulario html! Puede proteger su sitio de csrf agregando un encabezado adicional como X-CSRF-HEADER y comprobando su servidor.
Usted usa $.ajax de la biblioteca jQuery para una solicitud GET o POST . Usted es vulnerable si no hace ninguna comprobación del lado del servidor! jQuery agrega automáticamente un encabezado, X-REQUESTED-WITH , mientras realiza la solicitud $.ajax , que puede verificar del lado del servidor.
Utiliza otro método que no sea GET o POST , no es vulnerable ya que no puede enviar solicitudes entre sitios con otro método sin la autorización adicional de su sitio web. Aún así, este es realmente tu hielo (un error en el navegador o HTTP sepcs podría cambiar), por lo que también debes protegerlo contra csrf.
El valor del encabezado X-XSRF-TOKEN en su ejemplo es en el momento en que escribo inútil. Lo más importante es la presencia del encabezado en sí mismo, ya que solo se puede agregar un encabezado Cutstom con ajax que no es posible de forma cruzada entre sitios. Sin embargo, tenga en cuenta que esto puede cambiar en el futuro dependiendo de cómo evolucionen HTTP specs, por lo que aconsejaría verificar el valor del token.
Esa respuesta no es del todo correcta. CORS no se aplica si el atacante no está utilizando ajax. Por ejemplo, si su sitio web no bloquea el uso de IFrame con el encabezado X-FRAME-OPTIONS, un atacante podría simplemente ocultar un iframe en su página maliciosa y usar javascript para hacer un formulario.submit ().
Como CodesInChaos mencionó en su comentario, el escenario que acabo de mencionar solo funcionará si la solicitud no tiene ninguna autorización (la acción del controlador tiene un atributo [AllowAnonymous], en el caso de ASP.net), o El navegador pasa automáticamente el token de autenticación (como ocurre con las cookies).
Tenga en cuenta que si almacena el token de sesión en javascript, lo que debe hacer si está utilizando un encabezado de solicitud, los ataques XSS pueden ser mucho más devastadores, ya que un atacante podrá acceder al token de sesión y hacerse pasar por el token. sesión de víctimas. Es posible que desee considerar el uso de cookies tradicionales con el indicador HTTPOnly establecido para almacenar el token de autorización y agregar un token anti-CSRF a través de javascript.