Protection contre le « Cross site request forgery » (CSRF)Lien vers cette rubrique#

Comment l’utiliserLien vers cette rubrique#

Pour profiter de la protection CSRF dans les vues, procédez comme suit :

1. L’intergiciel CSRF est activé par défaut dans le réglage MIDDLEWARE_CLASSES. 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).

2. In any template that uses a POST form, use the csrf_token tag inside the <form> element if the form is for an internal URL, e.g.:

   Django template

   <form action="" method="post">{% csrf_token %}
   

   Par 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é.

3. Dans 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.

// using jQuery
function getCookie(name) {
    var cookieValue = null;
    if (document.cookie && document.cookie !== '') {
        var cookies = document.cookie.split(';');
        for (var i = 0; i < cookies.length; i++) {
            var cookie = jQuery.trim(cookies[i]);
            // Does this cookie string begin with the name we want?
            if (cookie.substring(0, name.length + 1) === (name + '=')) {
                cookieValue = decodeURIComponent(cookie.substring(name.length + 1));
                break;
            }
        }
    }
    return cookieValue;
}
var csrftoken = getCookie('csrftoken');

var csrftoken = Cookies.get('csrftoken');

function csrfSafeMethod(method) {
    // these HTTP methods do not require CSRF protection
    return (/^(GET|HEAD|OPTIONS|TRACE)$/.test(method));
}
$.ajaxSetup({
    beforeSend: function(xhr, settings) {
        if (!csrfSafeMethod(settings.type) && !this.crossDomain) {
            xhr.setRequestHeader("X-CSRFToken", csrftoken);
        }
    }
});

$httpProvider.defaults.xsrfCookieName = 'csrftoken';
$httpProvider.defaults.xsrfHeaderName = 'X-CSRFToken';

<form action="" method="post">{{ csrf_input }}

Requêtes rejetéesLien vers cette rubrique#

Par 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.

CSRF failures are logged as warnings to the django.request logger.

FonctionnementLien vers cette rubrique#

La protection CSRF est basée sur les éléments suivants :

1. Un cookie CSRF qui est défini à une valeur aléatoire (un nonce cryptographique indépendant de la session, comme on l’appelle), auquelle les autres sites n’auront pas accès.

   Ce cookie est créé par l’intergiciel CsrfViewMiddleware. Il est destiné à être permanent, mais comme il n’est pas possible d’installer un cookie qui n’expire jamais, 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).

   For security reasons, the value of the CSRF cookie is changed each time a user logs in.

2. Un champ de formulaire masqué avec le nom « csrfmiddlewaretoken » est présent dans tous les formulaires POST affichés. La valeur de ce champ correspond à la valeur du cookie CSRF.

   Cette action est effectuée par la balise de gabarit.

3. 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.

   Cette vérification est effectuée par l’intergiciel CsrfViewMiddleware.

4. 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’un nonce cryptographique indépendant 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.

It deliberately ignores GET requests (and other requests that are defined as “safe” by RFC 7231). These requests ought never to have any potentially dangerous side effects , and so a CSRF attack with a GET request ought to be harmless. RFC 7231 defines POST, PUT, and DELETE as “unsafe”, and all other methods are also assumed to be unsafe, for maximum protection.

La 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).

Mise en cacheLien vers cette rubrique#

Si 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
from django.views.decorators.csrf import csrf_protect

@cache_page(60 * 15)
@csrf_protect
def my_view(request):
    ...

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.

TestsLien vers cette rubrique#

Gé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 :

>>> from django.test import Client
>>> csrf_client = Client(enforce_csrf_checks=True)

LimitationsLien vers cette rubrique#

Les 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.

Cas particuliersLien vers cette rubrique#

Certaines 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.

from django.views.decorators.csrf import csrf_exempt, csrf_protect

@csrf_exempt
def my_view(request):

    @csrf_protect
    def protected_path(request):
        do_something()

    if some_condition():
       return protected_path(request)
    else:
       do_something_else()

Applications intégrées et applications réutilisablesLien vers cette rubrique#

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.

RéglagesLien vers cette rubrique#

Un certain nombre de réglages peuvent être utilisés pour contrôler le comportement anti-CSRF de Django :

• CSRF_COOKIE_AGE

• CSRF_COOKIE_DOMAIN

• CSRF_COOKIE_HTTPONLY

• CSRF_COOKIE_NAME

• CSRF_COOKIE_PATH

• CSRF_COOKIE_SECURE

• CSRF_FAILURE_VIEW

• CSRF_HEADER_NAME

• CSRF_TRUSTED_ORIGINS

Questions fréquentesLien vers cette rubrique#