Comments on: La protection CSRF de Django et les requêtes Ajax

By: loon

loon — Sun, 15 Jun 2014 21:50:17 +0000

Ce n’est pas géré par défault !

Je ne connais pas vraiment Django.
Mais sur Laravel on peu ajouter un jeton csrf sur toutes les routes en post par exemple, en une seule ligne dans le fichier de routing.

Ça doit sûrement exister sur Django.

By: Sam

Sam — Wed, 11 Jun 2014 14:42:36 +0000

Oui, logique, sinon un mec qui écoute sur la ligne peut récup le truc et le réutiliser.

By: JEDI_BC

JEDI_BC — Wed, 11 Jun 2014 14:03:56 +0000

@Sam : un token doit être utilisé pour une seule requête et une seule et regénéré ensuite (renvoyé par cookie du retour http)

@geekingfrog : seul l’id de session est stocké dans le cookie (enfin en PHP :p), les informations de la session comprenant le token sont elles stockées sur le serveur. Le but est de mixer le Synchronizer Token Pattern et le Double Submit Pattern pour renforcer encore plus la sécurité (voir mon lien précédent).

By: Sam

Sam — Wed, 11 Jun 2014 13:01:01 +0000

Du coup, pourquoi faire un token en plus ? Pourquoi ne pas juste utiliser l’id de session.

By: geekingfrog

geekingfrog — Wed, 11 Jun 2014 12:44:04 +0000

Si ça marchait out of the box avec le csrf dans les cookies, ça n’aurait aucune utilitée. Dans ce cas, si l’attaquant te leure pour que tu POST quelque chose sur le domaine visée, ton browser va envoyer les cookies avec. L’idée du token c’est de rajouter une donnée que l’attaquant ne peux pas deviner, donc la requete forgée va échouer.

En bref: les attaques csrf utilisent les cookies pour bypass l’authentication, donc il faut autre chose (un header typiquement).

@Jedi une troisième vérification sur la session??? Si la session est stockée dans un cookie, ça ne sert à rien non plus. Je suis pas sûr de comprendre là.

By: Paul

Paul — Wed, 11 Jun 2014 11:00:51 +0000

@Sam @JEDI_BC Ok l’idée est donc de le passer dans le header dans un champ spécial donc qui est différent d’une champ de cookie (la version Angular est confusing! Mais je vois avec la version Jquery). Merci!!

By: JEDI_BC

JEDI_BC — Wed, 11 Jun 2014 10:53:54 +0000

@Paul : le principe est de vérifier la correspondance du token dans le cookie et du token dans le form ou header (d’où le double dans double submit validation). Une attaque par csrf ne peut pas altérer les 2. On peut aussi ajouter une troisième vérification avec le token en session si on gère une session bien sur.

By: Sam

Sam — Wed, 11 Jun 2014 09:14:41 +0000

@JEDI_BC: ahhhhhhhhhhhhhhh ok. Merci mec !

@Paul: en fait, ce que JEDI veut dire, c’est que le token doit être présent à la fois dans le cookie ET dans un autre medium pour que le CSRF soit pris en compte. Le cookie ne suffit pas. Si on utilise un formulaire, on envoit le cookie automatiquement, mais il faut aussi le mettre dans un champ input caché. Si on envoie une requête Ajax, on envoit le cookie, mais il faut aussi le foutre dans le header.

By: Paul

Paul — Wed, 11 Jun 2014 07:58:15 +0000

@JEDI_BC, ce que je ne comprend toujours pas (dsl je me sens bête), c’est que:
1) Un cookie devrait être envoyé par défaut dès qu’on fait appel à un url du même domaine du cookie, Ajax ou pas. Donc je suis étonné et ne pige pas vraiment qu’il faille le rajouter à la main.
2) Mais j’ai compris qu’il faut d’une certaine manière “accéder à ce cookie spécial manuellement”, ce qui suppose que le JS est sur le bon nom de domaine, pour envoyer ce cookie crypté. Ce qui ne peut être fait à partir d’un autre site. Sinon cela serait complètement inutile car il suffirait simplement d’envoyer une requête ajax depuis un site pirate pour effectuer notre opération admin à son insu (puisque les cookies du domaine sont envoyés avec l’appel à ce domaine en ajax) – cf les pubs qui bardent de cookies partout et nous trackent.

By: JEDI_BC

JEDI_BC — Wed, 11 Jun 2014 06:56:56 +0000

@Paul, @Sam : Parce qu’il doit utiliser la méthode de “double submit cookies” pour sa validation et qu’il ne doit pas y avoir le champ token dans les datas ou form que tu envois donc il regarde dans les headers. Pour plus d’infos : https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookies