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 7231 Section 4.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 ci-dessous.
\nPour profiter de la protection CSRF dans les vues, procédez comme suit :
\nL’intergiciel CSRF est activé par défaut dans le réglage MIDDLEWARE. Si vous surchargez ce réglage, rappelez-vous que 'django.middleware.csrf.CsrfViewMiddleware' doit figurer avant les intergiciels qui comptent sur le fait que les attaques CSRF ont déjà été contrées.
Si vous le désactivez, ce qui n’est pas recommandé, vous pouvez utiliser csrf_protect() sur certaines vues que vous souhaitez protéger (voir ci-dessous).
Dans tout gabarit qui utilise un formulaire POST, utilisez la balise de gabarit csrf_token à l’intérieur de la balise HTML <form> si le formulaire renvoie vers une URL interne, par exemple :
<form method="post">{% csrf_token %}\nPar contre, il ne faut pas le faire pour les formulaires POST qui ciblent des URL externes, car cela entraînerait la divulgation du jeton CSRF, et conduirait ainsi à une vulnérabilité.
\nDans les fonctions de vue correspondantes, vérifiez que RequestContext est utilisé pour produire la réponse afin que {% csrf_token %} fonctionne correctement. Si vous utilisez la fonction render(), les vues génériques ou les applications contribuées, il n’y a pas de soucis à se faire car toutes ces vues utilisent RequestContext.
Même si la méthode ci-dessus peut être utilisée pour les requêtes AJAX POST, elle présente quelques inconvénients : il ne faut pas oublier de passer le jeton CSRF en même temps que les données POST à chaque requête POST. Pour cette raison, il y a une autre méthode : sur chaque XMLHttpRequest, définissez un élément d’en-tête X-CSRFToken (tel qu’indiqué par le réglage CSRF_HEADER_NAME) ayant la même valeur que le jeton CSRF. C’est souvent plus simple, parce que de nombreuses bibliothèques JavaScript fournissent des points d’extension qui permettent d’ajouter des éléments d’en-tête pour chaque requête.
Il faut d’abord obtenir le jeton CSRF. La façon de faire dépend de l’activation ou non des réglages CSRF_USE_SESSIONS et CSRF_COOKIE_HTTPONLY.
Pour terminer, il reste à effectivement définir l’en-tête sur la requête AJAX, tout en évitant que le jeton CSRF soit envoyé à d’autres domaines en utilisant settings.crossDomain dans les versions de jQuery 1.5.1 ou plus récentes :
\nfunction csrfSafeMethod(method) {\n // these HTTP methods do not require CSRF protection\n return (/^(GET|HEAD|OPTIONS|TRACE)$/.test(method));\n}\n$.ajaxSetup({\n beforeSend: function(xhr, settings) {\n if (!csrfSafeMethod(settings.type) && !this.crossDomain) {\n xhr.setRequestHeader("X-CSRFToken", csrftoken);\n }\n }\n});\nSi vous utilisez AngularJS 1.1.3 ou plus récente, il suffit de configurer le fournisseur $http avec les noms de cookie et d’en-tête :
$httpProvider.defaults.xsrfCookieName = 'csrftoken';\n$httpProvider.defaults.xsrfHeaderName = 'X-CSRFToken';\nLe moteur de gabarit Jinja2 de Django ajoute {{ csrf_input }} au contexte de tous les gabarits, ce qui est équivalent à {% csrf_token %} dans le langage de gabarit de Django. Par exemple :
<form method="post">{{ csrf_input }}\nPlutôt que d’ajouter CsrfViewMiddleware comme une protection générale, vous pouvez utiliser le décorateur csrf_protect, qui offre exactement la même fonctionnalité, sur les vues particulières qui ont besoin de la protection. Ce décorateur doit être utilisé à la fois sur les vues qui insèrent le jeton CSRF dans leur rendu, et sur celles qui acceptent les données de formulaire POST. (Il s’agit souvent de la même fonction de vue, mais pas toujours).
Le recours à l’utilisation seule du décorateur n’est pas recommandé, car si vous oubliez de l’utiliser, vous aurez un trou de sécurité. La stratégie « ceinture et bretelles » qui consiste à utiliser les deux convient tout à fait et n’entraînera qu’une surcharge minimale.
\nDécorateur qui fournit la protection similaire à l’intergiciel CsrfViewMiddleware pour une vue.
Utilisation :
\nfrom django.shortcuts import render\nfrom django.views.decorators.csrf import csrf_protect\n\n@csrf_protect\ndef my_view(request):\n c = {}\n # ...\n return render(request, "a_template.html", c)\nSi 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.
\nPar défaut, une réponse de type « 403 Forbidden » est renvoyée à l’utilisateur si une requête entrante ne satisfait pas les contrôles effectués par CsrfViewMiddleware. Ça ne devrait généralement apparaître que lorsqu’il s’agit d’une véritable attaque de type « Cross Site Request Forgery », ou lorsqu’en raison d’une erreur de programmation, le jeton CSRF n’a pas été inclus dans un formulaire de type POST.
La page d’erreur n’est toutefois pas très sympathique, de sorte que vous pouvez fournir votre propre vue pour traiter cette condition. Pour ce faire, il suffit de définir le réglage CSRF_FAILURE_VIEW.
Les échecs CSRF sont journalisés comme avertissements dans le journaliseur django.security.csrf.
\nLa protection CSRF est basée sur les éléments suivants :
\nUn cookie CSRF qui est basé sur une valeur secrète aléatoire auquel les autres sites n’auront pas accès.
\nCe cookie est créé par l’intergiciel CsrfViewMiddleware. Il est envoyé avec chaque réponse qui a appelé django.middleware.csrf.get_token() (la fonction utilisée en interne pour récupérer le jeton CSRF), s’il n’a pas déjà été défini pour la requête.
Afin de protéger contre les attaques BREACH, le jeton n’est pas simplement la valeur secrète ; un sel aléatoire est préfixé à la valeur et utilisé pour le brouiller.
\nPour des raisons de sécurité, la valeur secrète est modifiée chaque fois qu’un utilisateur se connecte.
\nUn champ de formulaire masqué nommé csrfmiddlewaretoken et présent dans tous les formulaires POST sortants. La valeur de ce champ est, encore une fois, la valeur secrète avec un sel qui est ajouté et utilisé pour le brouiller. Le sel est régénéré à chaque appel à get_token() afin que la valeur de champ de formulaire soit modifiée dans chacune des réponses.
Cette action est effectuée par la balise de gabarit.
\nPour 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.
De plus, pour les requêtes HTTPS, le contrôle strict du référant est effectué par CsrfViewMiddleware. 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. Ce réglage prend en compte les sous-domaines. 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 7231 Section 4.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 7231 Section 4.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\nSi la balise de gabarit csrf_token est utilisée par un gabarit (ou que la fonction get_token est appelée d’une autre façon), l’intergiciel CsrfViewMiddleware ajoute un cookie et un en-tête Vary: Cookie à la réponse. Cela signifie que l’intergiciel fonctionnera bien avec l’intergiciel de cache s’il est utilisé conformément aux instructions (UpdateCacheMiddleware doit être placé dans les réglages avant tout autre intergiciel).
Toutefois, si vous utilisez des décorateurs de cache sur des vues individuelles, l’intergiciel CSRF n’aura pas encore pu définir l’en-tête Vary ou le cookie CSRF, et la réponse sera mise en cache sans l’un ni l’autre. Dans ce cas, sur les vues qui nécessitent qu’un jeton CSRF soit inséré, vous devez utiliser le décorateur de fonction django.views.decorators.csrf.csrf_protect() en premier :
from django.views.decorators.cache import cache_page\nfrom django.views.decorators.csrf import csrf_protect\n\n@cache_page(60 * 15)\n@csrf_protect\ndef my_view(request):\n ...\nSi 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.
\nGénéralement, CsrfViewMiddleware gêne les tests des fonctions de vues, parce que le jeton CSRF doit être envoyé avec chaque requête POST. Le client HTTP de Django utilisé pour les tests a donc été modifié afin de marquer automatiquement les requêtes et ainsi d’informer l’intergiciel et le décorateur csrf_protect de manière à ce qu’ils ne rejettent pas ces requêtes. À tous les autres égards (par exemple, l’envoi des cookies, etc.), le comportement durant les tests est identique.
Si pour une raison quelconque vous voulez que le client HTTP utilisé pour les tests effectue des contrôles CSRF, vous pouvez créer une instance du client de test qui applique les vérifications CSRF :
\n>>> from django.test import Client\n>>> csrf_client = Client(enforce_csrf_checks=True)\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.
\nCertaines vues peuvent avoir des exigences inhabituelles qui impliquent qu’elles ne correspondent pas au modèle normal envisagé ici. Un certain nombre d’utilitaires peuvent être utiles dans ces situations. Les scénarios qui pourraient alors être nécessaires sont décrits dans la section suivante.
\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@csrf_exempt\ndef my_view(request):\n return HttpResponse('Hello world')\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@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.
\nLa plupart des vues nécessitent une protection CSRF, mais quelques-unes n’en ont pas besoin.
\nSolution : plutôt que de désactiver l’intergiciel et d’appliquer csrf_protect à toutes les vues qui en ont besoin, activez l’intergiciel et utilisez csrf_exempt().
Il y a des cas où CsrfViewMiddleware.process_view n’aura pas été exécuté avant votre vue - les gestionnaires d’erreurs 404 et 500, par exemple - mais vous avez quand même besoin du jeton CSRF dans un formulaire.
Solution : utilisez requires_csrf_token()
Certaines vues peuvent ne pas être protégées, peut-être exemptées par csrf_exempt, mais ont tout de même besoin d’inclure le jeton CSRF.
Solution : utilisez csrf_exempt() suivi de requires_csrf_token() (c’est à dire que requires_csrf_token doit être le décorateur le plus à l’intérieur).
Une vue a besoin de protection CSRF seulement quand un certain nombre de conditions sont remplies, et ne doit pas être protégée le reste du temps.
\nSolution : utilisez csrf_exempt() pour l’ensemble de la fonction de vue, et csrf_protect() spécifiquement pour le chemin qui doit être protégé. Exemple :
from django.views.decorators.csrf import csrf_exempt, csrf_protect\n\n@csrf_exempt\ndef my_view(request):\n\n @csrf_protect\n def protected_path(request):\n do_something()\n\n if some_condition():\n return protected_path(request)\n else:\n do_something_else()\nUne page effectue une requête POST via AJAX, et cette page n’a pas de formulaire HTML avec une balise csrf_token qui provoquerait la transmission du cookie CSRF.
Solution : utilisez ensure_csrf_cookie() sur la vue qui envoie la page.
Comme il est possible pour le développeur de désactiver l’intergiciel CsrfViewMiddleware, toutes les vues concernées dans les applications « contrib » de Django utilisent le décorateur csrf_protect pour garantir la protection de ces applications contre les attaques CSRF. Il est recommandé que les développeurs d’autres applications réutilisables qui souhaitent offrir les mêmes garanties utilisent également le décorateur csrf_protect sur leurs vues.
Un 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 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