Al implementar la protección CSRF, generalmente se usa una cookie CSRF que debe incluirse en el cuerpo de la solicitud. Esto evita los ataques CSRF porque el sitio web malicioso no puede leer las cookies del otro sitio web.
Esto es fundamentalmente incorrecto. Creo que malinterpretas el vector de ataque.
Un ataque CSRF (también llamado "sesión de sesión") se verá así:
- Hacker envía un correo electrónico cuidadosamente diseñado a millones de usuarios, y / o los engaña para que abran una página cuidadosamente diseñada con el diseño del atacante.
- De esos millones, algunos usuarios accederán al correo electrónico mientras su navegador ya haya iniciado sesión en un sitio web seguro y, por lo tanto, tenga la cookie de sesión
- Un GIF, enlace o secuencia de comandos en el correo electrónico o página maliciosa se dirige a una ubicación dentro del sitio web seguro
- Dado que el usuario ya ha iniciado sesión en el sitio, todas las cookies asociadas con ese sitio se envían automáticamente junto con la solicitud. Por lo tanto, el ataque puede "cabalgar" sobre la sesión legítima del usuario.
- En ningún momento el atacante aprende qué hay EN la cookie. Él solo lo está tomando prestado, a ciegas.
Una mitigación CSRF se basa en el hecho de que el ataque está diseñado con anticipación y no tiene capacidad para acceder al contenido de ninguna de las páginas seguras (solo puede emitir una solicitud a ciegas). Un token CSRF se incluye como una variable oculta en las páginas seguras del sitio; cuando la solicitud del atacante llega al sitio, sí tiene la cookie, pero no tendrá la variable oculta. El sitio puede validar la cookie contra la variable, y si la variable falta o es incorrecta, se deniega la solicitud.
Ciertamente es posible implementar una mitigación CSRF usando algún token en la URL (además de, no en lugar de, una cookie), pero este enfoque tiene ciertos problemas. Para ofrecer seguridad, el token debe cambiar ocasionalmente (a veces por sesión, a menudo por solicitud de página) y cuando cambie, invalidará cualquiera de los marcadores del usuario. Además, es extremadamente feo porque un usuario final puede ver lo que parece ser un libro de texto en la barra de direcciones.
NO debe implementar un mecanismo sin cookies que se basa únicamente en el token de la URL, ya que esto causa otros problemas de seguridad .