Estoy tratando de entender todo el problema con CSRF y las formas apropiadas para prevenirlo. (Recursos que he leído, entiendo y estoy de acuerdo con:Hoja de referencia de prevención de CSRF de OWASP, Preguntas sobre CSRF.)

Como lo entiendo, la vulnerabilidad en torno a CSRF se introduce al asumir que (desde el punto de vista del servidor web) una cookie de sesión válida en una solicitud HTTP entrante refleja los deseos de un usuario autenticado. Pero todas las cookies para el dominio de origen están conectadas mágicamente a la solicitud por el navegador, por lo que realmente todo el servidor puede deducir que la presencia de una cookie de sesión válida en una solicitud es que la solicitud proviene de un navegador que tiene una sesión autenticada; no puede asumir nada sobre elcódigo ejecutándose en ese navegador, o si realmente refleja los deseos del usuario. La forma de evitar esto es incluir información de autenticación adicional (el "token CSRF") en la solicitud, que se transmite por algún otro medio que no sea el manejo automático de cookies del navegador. En términos generales, entonces, la cookie de sesión autentica al usuario / navegador y el token CSRF autentica el código que se ejecuta en el navegador.

Entonces, en pocas palabras, si está utilizando una cookie de sesión para autenticar a los usuarios de su aplicación web, también debe agregar un token CSRF a cada respuesta, y requerir un token CSRF coincidente en cada solicitud (mutación). El token CSRF luego realiza un viaje de ida y vuelta del servidor al navegador, y le demuestra al servidor que la página que realiza la solicitud es aprobada (e incluso) por ese servidor.

En mi pregunta, que trata sobre el método de transporte específico utilizado para ese token CSRF en ese viaje de ida y vuelta.

Parece común (por ejemplo, enAngularJS, Django, Carriles) para enviar el token CSRF del servidor al cliente como una cookie (es decir, en un encabezado Set-Cookie), y luego hacer que Javascript del cliente lo elimine de la cookie y lo adjunte como un encabezado XSRF-TOKEN separado para enviarlo a el servidor.

(Un método alternativo es el recomendado por ej.Exprimir, donde el token CSRF generado por el servidor se incluye en el cuerpo de la respuesta a través de la expansión de la plantilla del lado del servidor, que se adjunta directamente al código / marcado que lo devolverá al servidor, por ejemplo. como una entrada de forma oculta. Ese ejemplo es una forma más web 1.0 de hacer las cosas, pero generalizaría bien a un cliente más JS-pesado.)

¿Por qué es tan común utilizar Set-Cookie como el transporte descendente para el token CSRF? ¿Por qué es una buena idea? Me imagino que los autores de todos estos marcos consideraron sus opciones cuidadosamente y no se equivocaron. Pero a primera vista, el uso de cookies para solucionar lo que es esencialmente una limitación de diseño de las cookies parece una tontería. De hecho, si usara cookies como el transporte de ida y vuelta (Set-Cookie: encabezado en sentido descendente para que el servidor le indique al token CSRF, y Cookie: encabezado en sentido ascendente para que el navegador lo devuelva al servidor) reintroduciría la vulnerabilidad que están tratando de arreglar

Me doy cuenta de que los marcos anteriores no usan cookies para todo el viaje de ida y vuelta para el token CSRF; usan Set-Cookie en sentido descendente, y luego otra cosa (por ejemplo, un encabezado de X-CSRF-Token) en sentido ascendente, y esto elimina la vulnerabilidad. Pero incluso usar Set-Cookie como el transporte descendente es potencialmente engañoso y peligroso; el navegador ahora adjuntará el token CSRF a cada solicitud, incluidas las solicitudes XSRF maliciosas genuinas; en el mejor de los casos, eso hace que la solicitud sea más grande de lo que debe ser y, en el peor, algún código de servidor bien intencionado pero mal orientado podría intentar usarlo, lo que sería realmente malo. Y además, dado que el destinatario real del token CSRF es Javascript del lado del cliente, esto significa que esta cookie no puede ser protegida con solo http. Por lo tanto, enviar el token CSRF en sentido descendente en un encabezado Set-Cookie me parece muy poco óptimo.