Comments on: La protection CSRF de Django et les requêtes Ajax http://sametmax.com/la-protection-csrf-de-django-et-les-requetes-ajax/ Du code, du cul Sat, 07 Nov 2015 11:08:18 +0000 hourly 1 http://wordpress.org/?v=4.1 By: loon http://sametmax.com/la-protection-csrf-de-django-et-les-requetes-ajax/#comment-55476 Sun, 15 Jun 2014 21:50:17 +0000 http://sametmax.com/?p=10438#comment-55476 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 http://sametmax.com/la-protection-csrf-de-django-et-les-requetes-ajax/#comment-49335 Wed, 11 Jun 2014 14:42:36 +0000 http://sametmax.com/?p=10438#comment-49335 Oui, logique, sinon un mec qui écoute sur la ligne peut récup le truc et le réutiliser.

]]>
By: JEDI_BC http://sametmax.com/la-protection-csrf-de-django-et-les-requetes-ajax/#comment-49300 Wed, 11 Jun 2014 14:03:56 +0000 http://sametmax.com/?p=10438#comment-49300 @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 http://sametmax.com/la-protection-csrf-de-django-et-les-requetes-ajax/#comment-49265 Wed, 11 Jun 2014 13:01:01 +0000 http://sametmax.com/?p=10438#comment-49265 Du coup, pourquoi faire un token en plus ? Pourquoi ne pas juste utiliser l’id de session.

]]>
By: geekingfrog http://sametmax.com/la-protection-csrf-de-django-et-les-requetes-ajax/#comment-49257 Wed, 11 Jun 2014 12:44:04 +0000 http://sametmax.com/?p=10438#comment-49257 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 http://sametmax.com/la-protection-csrf-de-django-et-les-requetes-ajax/#comment-49205 Wed, 11 Jun 2014 11:00:51 +0000 http://sametmax.com/?p=10438#comment-49205 @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 http://sametmax.com/la-protection-csrf-de-django-et-les-requetes-ajax/#comment-49201 Wed, 11 Jun 2014 10:53:54 +0000 http://sametmax.com/?p=10438#comment-49201 @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 http://sametmax.com/la-protection-csrf-de-django-et-les-requetes-ajax/#comment-49150 Wed, 11 Jun 2014 09:14:41 +0000 http://sametmax.com/?p=10438#comment-49150 @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 http://sametmax.com/la-protection-csrf-de-django-et-les-requetes-ajax/#comment-49117 Wed, 11 Jun 2014 07:58:15 +0000 http://sametmax.com/?p=10438#comment-49117 @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 http://sametmax.com/la-protection-csrf-de-django-et-les-requetes-ajax/#comment-49054 Wed, 11 Jun 2014 06:56:56 +0000 http://sametmax.com/?p=10438#comment-49054 @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

]]>