L’intergiciel et les balises de gabarit CSRF permettent de se protéger facilement contre les attaques de type Cross Site Request Forgeries. Ce type d’attaque se produit quand un site Web malveillant contient un lien, un bouton de formulaire ou un peu de JavaScript qui est destiné à effectuer une action sur votre site web, en utilisant les informations d’identification d’un utilisateur connecté qui visite le site malveillant dans son navigateur. Un type d’attaque liée est également couverte : celle du « login CSRF », où un site attaquant piège le navigateur d’un utilisateur en se connectant à un site avec les informations d’identification de quelqu’un d’autre.
\nLa première ligne de défense contre les attaques CSRF est de s’assurer que les requêtes GET (et les autres méthodes « sûres », telles que définies par RFC 9110 Section 9.2.1) sont sans effet de bord. Les appels par des méthodes « non sûres », comme POST, PUT et DELETE, peuvent ensuite être protégés en suivant les étapes décrites dans Comment utiliser la protection CSRF de Django.
\nLa protection CSRF est basée sur les éléments suivants :
\nUn cookie CSRF qui est une valeur secrète aléatoire auquel les autres sites n’auront pas accès.
\nCsrfViewMiddleware envoie ce cookie avec la réponse chaque fois que django.middleware.csrf.get_token() est appelée. Il peut aussi l’envoyer dans d’autres cas. Pour des raisons de sécurité, la valeur de la partie secrète est modifiée chaque fois qu’un utilisateur se connecte.
Un champ de formulaire masqué avec le nom « csrfmiddlewaretoken » est présent dans tous les formulaires POST affichés.
\nAfin de protéger contre les attaques de type BREACH, la valeur de ce champ ne correspond pas simplement à la valeur secrète. Elle est obscurcie différemment pour chaque réponse à l’aide d’un masque. Le masque est généré aléatoirement lors de chaque appel à get_token() afin que la valeur du champ de formulaire soit différente à chaque fois.
Cette action est effectuée par la balise de gabarit csrf_token.
Pour toutes les requêtes entrantes qui n’utilisent pas les méthodes HTTP GET, HEAD, OPTIONS ou TRACE, un cookie CSRF doit être présent, et le champ « csrfmiddlewaretoken » doit être présent et correct. Si ce n’est pas le cas, l’utilisateur obtiendra une erreur 403.
\nLors de la validation de la valeur de champ csrfmiddlewaretoken, seule la valeur secrète, et non pas le jeton complet, est comparée avec la valeur secrète du contenu du cookie. Cela permet d’utiliser des jetons qui changent constamment. Alors que chaque requête peut utiliser son propre jeton, la valeur secrète reste commune à toutes.
Cette vérification est effectuée par l’intergiciel CsrfViewMiddleware.
CsrfViewMiddleware compare l’en-tête Origin, si fourni par le navigateur, avec l’hôte actuel et le réglage CSRF_TRUSTED_ORIGINS. Cela ajoute une protection contre les attaques de sous-domaines croisés.
De plus, pour les requêtes HTTPS, si l’en-tête Origin n’est pas présent, le CsrfViewMiddleware effectue un contrôle strict du référant. Cela signifie que même si un sous-domaine peut définir ou modifier des cookies pour votre domaine, il ne peut pas forcer un utilisateur à envoyer des données à votre application car cette requête ne viendrait pas de votre domaine exact.
Cela protège aussi contre une attaque de type « Man-In-The-Middle » qui est possible sous HTTPS lors de l’utilisation d’une valeur secrète indépendante de la session, parce que les en-têtes HTTP Set-Cookie sont (malheureusement) acceptés par les clients, même quand ils parlent à un site en HTTPS. (La vérification du référant n’est pas faite pour les requêtes HTTP car la présence de l’en-tête Referer n’est pas suffisamment fiable sous HTTP.)
Si le réglage CSRF_COOKIE_DOMAIN est défini, le référant est comparé avec lui. Il est possible d’autoriser les requêtes inter-domaines en incluant un point en premier. Par exemple, CSRF_COOKIE_DOMAIN = '.exemple.com' autorise les requêtes POST depuis www.exemple.com et api.exemple.com. Si le réglage n’est pas défini, le référant doit alors correspondre à l’en-tête HTTP Host.
L’extension des référants acceptés au-delà de l’hôte courant ou du domaine du cookie peut se faire avec le réglage CSRF_TRUSTED_ORIGINS.
Cela garantit que seuls les formulaires originaires de domaines de confiance peuvent être utilisés pour renvoyer des données avec une requête POST.
\nLes requêtes GET sont volontairement ignorées (ainsi que les autres requêtes définies comme « sûres » par la RFC 9110 Section 9.2.1). Ces requêtes ne devraivent jamais avoir d’effets secondaires potentiellement dangereux, et de cette manière une attaque CSRF avec une requête GET doit être inoffensive. La RFC 9110 Section 9.2.1 définit les méthodes POST, PUT et DELETE comme « non sûres », et toutes les autres méthodes sont aussi supposées être dangereuses, pour que la protection soit maximale.
\nLa protection CRSF ne peut pas protéger contre les attaques de « l’homme du milieu », c’est pourquoi il faut utiliser HTTPS avec Sécurité de transport HTTP stricte (HSTS). Il suppose également la validation de l’en-tête HOST et que le site ne comporte pas de vulnérabilités de scripts inter-sites (parce que ce type de vulnérabilité permet déjà à un attaquant de faire ce qu’une vulnérabilité CSRF permet de faire, et plus encore).
\n\nLes sous-domaines d’un site peuvent placer des cookies sur le client pour l’ensemble du domaine. En définissant le cookie et en utilisant le jeton correspondant, les sous-domaines seront en mesure de contourner la protection CSRF. La seule façon d’éviter cela est de s’assurer que les sous-domaines sont contrôlés par des utilisateurs de confiance (ou, au moins ne sont pas en mesure de définir des cookies). Notez que même sans CSRF, il existe d’autres vulnérabilités, comme la fixation de session, qui font que donner des sous-domaines à des tierces parties non sûres est une mauvaise idée ; ces vulnérabilités ne peuvent pas facilement être résolues avec les navigateurs actuels.
\nLes exemples ci-dessous s’appliquent à des vues basées sur des fonctions. Si vous utilisez des vues fondées sur les classes, vous pouvez vous référer à la Décoration des vues fondées sur les classes.
\nCe décorateur marque une vue comme étant exempte de la protection assurée par l’intergiciel. Exemple :
\nfrom django.http import HttpResponse\nfrom django.views.decorators.csrf import csrf_exempt\n\n\n@csrf_exempt\ndef my_view(request):\n return HttpResponse("Hello world")\nDécorateur qui fournit la protection CsrfViewMiddleware pour une vue.
Utilisation :
\nfrom django.shortcuts import render\nfrom django.views.decorators.csrf import csrf_protect\n\n\n@csrf_protect\ndef my_view(request):\n c = {}\n # ...\n return render(request, "a_template.html", c)\nNormalement, la balise de gabarit csrf_token ne fonctionnera pas si CsrfViewMiddleware.process_view ou un équivalent comme csrf_protect n’a pas été utilisé. Le décorateur de vue requires_csrf_token peut être utilisé pour s’assurer que la balise de gabarit fonctionne. Ce décorateur fonctionne de façon similaire à csrf_protect, mais ne rejette jamais une demande entrante.
Exemple :
\nfrom django.shortcuts import render\nfrom django.views.decorators.csrf import requires_csrf_token\n\n\n@requires_csrf_token\ndef my_view(request):\n c = {}\n # ...\n return render(request, "a_template.html", c)\nCe décorateur force une vue à envoyer le cookie CSRF.
\nUn certain nombre de réglages peuvent être utilisés pour contrôler le comportement anti-CSRF de Django :
\n\nNon, délibérément pas. Le fait de ne pas lier la protection CSRF à une session permet d’utiliser la protection sur des sites tels que pastebin qui autorisent des envois de données par des utilisateurs anonymes et qui n’ont pas de session.
\nSi vous souhaitez stocker le jeton CSRF dans la session de l’utilisateur, définissez le réglage CSRF_USE_SESSIONS.
Pour des raisons de sécurité, les jetons CSRF subissent une rotation lors de chque connexion d’utilisateur. Toute page contenant un formulaire généré avant une connexion possédera un ancien jeton CSRF non valide et devra être rechargée. Cela peut arriver si un utilisateur utilise le bouton « Retour » après une connexion ou s’il se connecte dans un autre onglet du navigateur.
\n