Por lo que leí aquí , los tokens CSRF del encabezado de la cookie no pueden Ser leído debido a la política del mismo origen.
¿Es suficiente comparar el token CSRF en el encabezado de la cookie con el elemento oculto del formulario?
Con este método, la implementación del token CSRF elimina la necesidad de guardar el token CSRF en el servidor; ¿Es este un enfoque correcto?
¿Es suficiente comparar el token CSRF en el encabezado de la cookie con el elemento oculto del formulario?
Un token aleatorio que tiene que ser el mismo en la cookie y la forma es una estrategia común contra XSRF, la "cookie de envío doble". Es usado, por ejemplo, por Django, por lo que claramente algunos lo consideran suficiente.
Sin embargo, es más débil que el patrón de "token de sincronizador" recomendado generalmente (por ejemplo, por OWASP), en el que el token de forma debe coincidir con un token almacenado en el servidor y asociado a la sesión.
Personalmente, no elegiría este método para un sitio sensible.
El ataque al que la cookie de envío doble es vulnerable, y el token del sincronizador no lo es, es el forzado de cookies.
Los tokens CSRF del encabezado de la cookie no se pueden leer debido a la política del mismo origen.
En general, es difícil leer una cookie de otro origen, por lo que las rutas para hacerlo (por ejemplo, XSS, MitM) generalmente significan que ya debe haber comprometido el sitio bastante sólidamente.
Sin embargo, escribir cookies no está tan bloqueado, gracias a un diseño deficiente en la especificación de cookie original. Lo más importante es que un sitio vecino malintencionado o comprometido en dodgy.example.com puede escribir una cookie con el dominio establecido para example.com que será leído por sensitive.example.com . Además, si bien un sitio protegido por HTTPS es seguro en contra de que sus cookies sean leídas por un hombre en el medio del ataque de nivel de red, es posible que un MitM genere tráfico a un dominio vecino no protegido por HTTPS que no lo hace. ni siquiera es necesario que existan, y use ese dominio vecino para establecer una cookie que no sea secure que será leída por el sitio HTTPS de la víctima. Y hay algunos otros ataques que podrían usarse para forzar cookies, por ejemplo, inyección de encabezado.
Al forzar una cookie en el sitio de la víctima, el atacante sabe cuál debe ser el token en el formulario y, por lo tanto, puede incluirlo en un formulario de sitios cruzados, evitando la comprobación XSRF. Esto constituye una elevación del ataque de uno ligeramente débil a uno más fuerte.
No es suficiente para validar tokens CSRF en el cliente, porque no puedes saber si el cliente es el usuario u otro sitio que se hace pasar por el usuario.
Debe comparar el token enviado por el usuario con el token que ha almacenado en el servidor.
El token CSRF debe verificarse en el lado del servidor.
Dicho esto, el token a menudo se almacena en una cookie, por lo que su enfoque es correcto.
CSRF funciona así:
Para solicitud:
Lea otras preguntas en las etiquetas web-application csrf