Commits

Anonymous committed 21cb84a

Ajout de la traduction de ref/contrib/csrf.txt

Comments (0)

Files changed (1)

docs/ref/contrib/csrf.txt

+.. _ref-contrib-csrf:
+
+================================================
+Protection contre les Cross Site Request Forgery
+================================================
+
+.. module:: django.contrib.csrf
+   :synopsis: Protège contre les Cross Site Request Forgeries
+
+La classe CsrfMiddleware fournie une protection facile à mettre en oeuvre
+contre les `Cross Site Request Forgeries`_. Ce type d'attaque survient lorsqu'un
+site web malicieux crée un lien ou un bouton de formulaire dans le but
+d'effectuer une action sur votre site, utilisant les données d'un utilisateur
+enregistré qui est dupé en cliquant sur le lien dans son navigateur.
+
+La première défense contre les attaques CSRF est de s'assurer que les
+requêtes GET sont libres de tout effet de bord. Les requêtes POST peuvent
+être ensuite protégées en ajoutant ce middleware dans votre liste de 
+middleware installés.
+
+.. _Cross Site Request Forgeries:  http://www.squarefree.com/securitytips/web-developers.html#CSRF
+
+Comment l'utiliser
+==================
+
+Ajoutez le middleware ``'django.contrib.csrf.middleware.CsrfMiddleware'``
+à votre liste de classes de middleware, ``MIDDLEWARE_CLASSES``. Il a besoin
+de traiter la réponse après le SessionMiddleware, donc nécessite d'être
+placé avant dans la liste. Il doit aussi traiter la réponse avant que des
+choses telles que la compression ne survienne dans la réponse, donc il doit
+être placé après le GZipMiddleware dans la liste.
+
+Comment ça marche
+=================
+
+CsrfMiddleware effectue deux choses:
+
+1. Il modifie les requêtes sortantes en ajoutant un champ de formulaire
+   caché à tous les formulaires 'POST', avec le nom 'csrfmiddlewaretoken'
+   et une valeur qui est un hash de l'identifiant de session plus un secret.
+   Si aucun identifiant de session n'est présent, cette modification de 
+   la réponse n'est pas effectuée, entraînant donc une petite pénalité
+   sur la performance pour les requêtes n'ayant pas de session.
+
+2. Sur toutes les requêtes POST entrantes qui on un cookie de session présent,
+   il vérifie que le 'csrfmiddlewaretoken' est présente et valide. S'il
+   ne l'est pas, l'utilisateur recevra une erreur 403.
+
+Cela permet de s'assurer que seuls les formulaires provenant de votre site
+peuvent être utilisés pour soumettre des données POST.
+
+Il cible délibérément et seulement les requêtes HTTP POST (et les formulaires
+POST correspondants). Les requêtes GET ne devraient jamais contenir d'effets
+de bord potentiellement exploitables (voir `9.1.1 Méthodes sécurisées, HTTP 1.1, RFC 2616`_),
+ainsi une attaque CSRF avec une requête GET restera toujours inoffensive.
+
+Les requêtes POST qui ne sont pas suivies par un cookie de session ne sont
+pas protégées, mais n'ont pas besoin de l'être, puisque le site 'attaquant'
+pourrait effectuer ce type de requêtes de toute façon.
+
+Le Content-Type est vérifié avant de modifier la réponse, et seules les 
+pages servies en tant que 'text/html' ou 'application/xml+xhtml' sont modifiées.
+
+.. _9.1.1 Méthodes sécurisées, HTTP 1.1, RFC 2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
+
+Limitations
+===========
+
+CsrfMiddleware nécessite le framework de session de Django pour fonctionner.
+Si vous avez un système personnalisé d'authentification qui enregistre les
+cookies manuellement ou ce genre de chose, il ne vous sera d'aucune aide.
+
+Si votre application crée des pages HTML et des formulaires de manière non
+usuelle (e.g. elle envoie des morceaux d'HTML via des appels javascript
+document.write) vous pourriez contourner le filtre ajoutant le champ caché
+dans le formulaire, qui dans un tel cas fera systématiquement échouer la
+soummission du formulaire. Il sera toujours possible d'utiliser le middleware
+fourni, si vous trouvez un moyen d'obtenir la donnée CSRF et de vous assurer
+qu'elle soit incluse quand votre formulaire est soumis.