##Impact Cross-Site Request Forgery (CSRF) permet à un attaquant de tromper le navigateur d'une victime pour qu'il effectue des actions indésirables sur un autre site Web sur lequel la victime est actuellement authentifiée. Étant donné que les navigateurs incluent automatiquement les informations d'identification ambiantes telles que les cookies dans les requêtes, un attaquant peut forger des opérations de changement d'état (telles que la modification des mots de passe, la suppression de données ou le lancement de transactions) à l'insu de l'utilisateur.
Cause première
La cause fondamentale du CSRF est le comportement par défaut du navigateur Web consistant à envoyer des cookies associés à un domaine chaque fois qu'une demande est faite à ce domaine, quelle que soit l'origine de la demande [S1]. Sans validation spécifique indiquant qu'une requête a été intentionnellement déclenchée à partir de la propre interface utilisateur de l'application, le serveur ne peut pas faire la distinction entre une action utilisateur légitime et une action falsifiée.
Mécanismes de protection CSRF de Django
Django fournit un système de défense intégré pour atténuer ces risques grâce à l'intégration de middleware et de modèles [S2].
Activation du middleware
Le django.middleware.csrf.CsrfViewMiddleware est responsable de la protection CSRF et est généralement activé par défaut [S2]. Il doit être positionné avant tout middleware de vue qui suppose que les attaques CSRF ont déjà été traitées [S2].
Implémentation du modèle
Pour tout formulaire POST interne, les développeurs doivent inclure la balise {% csrf_token %} dans l'élément <form> [S2]. Cela garantit qu'un jeton secret unique est inclus dans la demande, que le serveur valide ensuite par rapport à la session de l'utilisateur.
Risques de fuite de jetons
Un détail d'implémentation essentiel est que le {% csrf_token %} ne doit jamais être inclus dans les formulaires ciblant les URL externes [S2]. Cela entraînerait la fuite du jeton CSRF secret à un tiers, compromettant potentiellement la sécurité de la session de l'utilisateur [S2].
Défense au niveau du navigateur : cookies SameSite
Les navigateurs modernes ont introduit l'attribut SameSite pour l'en-tête Set-Cookie afin de fournir une couche de défense en profondeur [S1].
- Strict : Le cookie n'est envoyé que dans un contexte propriétaire, ce qui signifie que le site dans la barre d'URL correspond au domaine du cookie [S1].
- Lax : Le cookie n'est pas envoyé sur les sous-requêtes intersites (telles que des images ou des cadres) mais est envoyé lorsqu'un utilisateur navigue vers le site d'origine, par exemple en suivant un lien standard [S1].
Comment FixVibe le teste
FixVibe inclut désormais la protection CSRF en tant que contrôle actif sécurisé. Après la vérification du domaine, active.csrf-protection inspecte les formulaires de changement d'état découverts, vérifie les entrées en forme de jeton CSRF et les signaux de cookie SameSite, puis tente une soumission d'origine falsifiée à faible impact et ne signale que lorsque le serveur l'accepte. Les vérifications des cookies signalent également les attributs SameSite faibles qui réduisent la défense en profondeur du CSRF.