Impacto
La falsificación de solicitudes entre sitios (CSRF) permite a un atacante engañar al navegador de la víctima para que realice acciones no deseadas en un sitio web diferente en el que la víctima está actualmente autenticada. Debido a que los navegadores incluyen automáticamente credenciales ambientales como cookies en las solicitudes, un atacante puede falsificar operaciones de cambio de estado (como cambiar contraseñas, eliminar datos o iniciar transacciones) sin el conocimiento del usuario.
Causa raíz
La causa fundamental de CSRF es el comportamiento predeterminado del navegador web de enviar cookies asociadas con un dominio cada vez que se realiza una solicitud a ese dominio, independientemente del origen de la solicitud [S1]. Sin una validación específica de que una solicitud fue activada intencionalmente desde la propia interfaz de usuario de la aplicación, el servidor no puede distinguir entre una acción de usuario legítima y una falsificada.
Mecanismos de protección CSRF de Django
Django proporciona un sistema de defensa integrado para mitigar estos riesgos mediante la integración de plantillas y middleware [S2].
Activación de middleware
django.middleware.csrf.CsrfViewMiddleware es responsable de la protección CSRF y normalmente está habilitado de forma predeterminada [S2]. Debe colocarse antes de cualquier middleware de vista que suponga que los ataques CSRF ya se han manejado [S2].
Implementación de plantilla
Para cualquier formulario POST interno, los desarrolladores deben incluir la etiqueta {% csrf_token %} dentro del elemento <form> [S2]. Esto garantiza que se incluya un token secreto único en la solicitud, que luego el servidor valida con la sesión del usuario.
Riesgos de fuga de tokens
Un detalle de implementación fundamental es que {% csrf_token %} nunca debe incluirse en formularios dirigidos a URL externas [S2]. Hacerlo filtraría el token CSRF secreto a un tercero, comprometiendo potencialmente la seguridad de la sesión del usuario [S2].
Defensa a nivel del navegador: cookies del mismo sitio
Los navegadores modernos han introducido el atributo SameSite para el encabezado Set-Cookie para proporcionar una capa de defensa en profundidad [S1].
- Estricto: La cookie solo se envía en un contexto propio, lo que significa que el sitio en la barra de URL coincide con el dominio de la cookie [S1].
- Lax: La cookie no se envía en subsolicitudes entre sitios (como imágenes o marcos), sino que se envía cuando un usuario navega al sitio de origen, por ejemplo, siguiendo un enlace estándar [S1].
Cómo lo prueba FixVibe
FixVibe ahora incluye protección CSRF como verificación activa cerrada. Después de la verificación del dominio, active.csrf-protection inspecciona los formularios de cambio de estado descubiertos, busca entradas en forma de token CSRF y señales de cookies de SameSite, luego intenta un envío de origen falsificado de bajo impacto y solo informa cuando el servidor lo acepta. Las comprobaciones de cookies también señalan atributos débiles de SameSite que reducen la defensa en profundidad de CSRF.