¿Es suficiente la protección CSRF incorporada de Django?

Django está utilizando Double-Submit Cookie y se acepta como Un método seguro de prevención CSRF. ¿Por qué? Porque, Es imposible que un atacante controle la cookie archivada en un ataque CSRF . Un ataque CSRF se basa en el hecho de que el navegador administra las cookies, e incluirá cookies asociadas con un dominio de destino en la solicitud HTTP falsificada. Es posible leer y modificar las cookies que no son solo HTTP usando XSS, sin embargo, casi todas las medidas Anti-CSRF pueden verse afectadas por XSS.

Para responder a su pregunta:
Sí, el sistema de protección CSRF de Django evitará que un ataque CSRF tenga éxito, siempre y cuando la aplicación no sea vulnerable a XSS.

La protección CSRF de Django no se rompe per se; generalmente se considera suficiente para muchas aplicaciones.

Pero, de hecho, el modelo de "cookie de doble envío" significa que la protección CSRF fallará en caso de que un atacante pueda colocar una cookie en el navegador de un usuario: el atacante podría configurar la cookie y luego enviar inmediatamente un formulario con el mismo valor en su campo token. Esto significa que hay una ruta de escalada potencial desde el forzado de cookies a CSRF, y esto puede ser inaceptable para aplicaciones más críticas para la seguridad.

El forzado de cookies no es generalmente un simple ataque en sí mismo. La política del mismo origen normalmente debería evitar que un sitio atacante configure una cookie en otro sitio. Si el sitio de destino tiene un defecto de XSS, obviamente, puede establecer / obtener cookies, pero si tiene XSS que ya ha perdido tanto que no tiene sentido preocuparse por CSRF.

Donde esto puede caer es el alojamiento de factores que pueden estar fuera de su control como autor de la aplicación:

1. Cuando su sitio está en HTTPS y el atacante tiene un intermediario contra un usuario. Aunque no pueden falsificar su sitio web HTTPS, pueden dirigir al usuario a una dirección HTTP en el mismo nombre de host, y desde allí escribir una cookie que el navegador enviará a su sitio HTTPS más adelante. (Esto se puede mitigar un poco usando el encabezado Strict-Transport-Security ).

2. Si su sitio está en a.example.com y hay otra aplicación ejecutándose en b.example.com que es vulnerable a XSS, se podría abusar de esa aplicación para establecer una cookie en todo example.com , que luego sería enviado por el navegador a su aplicación en a.example.com .

Es una debilidad de diseño de las cookies que una aplicación no puede saber si las cookies se configuraron originalmente con las propiedades coincidentes domain y secure , y que si se configuran dos cookies con el mismo nombre con domain / secure de los resultados son esencialmente indefinidos.

Los enfoques de "token de sincronizador" y "token encriptado" (HMAC) incluyen un secreto del lado del servidor desconocido para el atacante que evita la escalada de forzamiento de cookies a CSRF.

Desafortunadamente, Django no se presta para una sustitución limpia de la funcionalidad compartida. Para mejorar o reemplazar el mecanismo CSRF sin romper todas las aplicaciones que dependen de él, se requieren un montón de parches de monos feos.