Note de l'auteur :
En lisant ce blogue, j'ai reconnu la conversation classique : avant de pouvoir expliquer ce qu'est une CSRF, il faut mettre en scène l'ensemble (la victime, le site vulnérable aux XSS, l'internaute innocent), puis expliquer aussi les XSS. Au final, si l'interlocuteur ne comprend que la moitié du schéma, il écarte le tout du revers de la main, et dis : "bah, j'ai mis des filtres, donc pas de XSS chez moi."
En fait, être vulnérable aux CSRF est distinct de la XSS. Il faut se poser la question : "Quelles sont les opérations sur mon site qui peuvent être simulées entièrement en JavaScript ou bien avec une URL seule.". Par exemple, si vous pouvez effacer des billets de votre blogue avec une URL du type 'http://www.site.net/efface.php?id=10", alors vous êtes vulnérables aux CSRF. L'utilisation de JavaScript permet ici de dépasser le stade de la simple URL, et de faire des POST, ou d'autres manipulations complexes, comme des enchaînements de pages.
Le danger vient donc du fait que les opérations sur votre site peuvent être exécutées de manière automatisées, sans intervention de l'utilisateur. Ce sera donc le vecteur de l'attaque CSRF. Il reste maintenant à trouver un site ayant une XSS (le site victime final ou bien un autre, cela n'a pas d'importance. Piochez chez xssed pour avoir de belles listes de sites populaires), et un utilisateur ayant suffisamment de droits.
C'est exactement le problème qui a été rapporté sur GMail récemment : une fonction anodine, l'ajout de filtre, peut être scriptée. On peut donc pousser un utilisateur ayant un compte GMail à installer un filtre automatique qui transmet les messages à une autre adresse.
Lorsque vous testerez la sécurité du site, demandez-vous si vous ne pourriez pas écrire un script JavaScript pour automatiser les opérations critiques. Si c'est le cas, vous avez votre vecteur. Pour les bloquer, il faut passer par des informatiques auxquelles JavaScript n'a pas acces, comme une demande de mot de passe, des captcha, ou des technologies connexes (images, animations, confirm(), etc).
- One more reason why CSRF sucks hard
- Google GMail E-mail Hijack Technique
En lisant ce blogue, j'ai reconnu la conversation classique : avant de pouvoir expliquer ce qu'est une CSRF, il faut mettre en scène l'ensemble (la victime, le site vulnérable aux XSS, l'internaute innocent), puis expliquer aussi les XSS. Au final, si l'interlocuteur ne comprend que la moitié du schéma, il écarte le tout du revers de la main, et dis : "bah, j'ai mis des filtres, donc pas de XSS chez moi."
En fait, être vulnérable aux CSRF est distinct de la XSS. Il faut se poser la question : "Quelles sont les opérations sur mon site qui peuvent être simulées entièrement en JavaScript ou bien avec une URL seule.". Par exemple, si vous pouvez effacer des billets de votre blogue avec une URL du type 'http://www.site.net/efface.php?id=10", alors vous êtes vulnérables aux CSRF. L'utilisation de JavaScript permet ici de dépasser le stade de la simple URL, et de faire des POST, ou d'autres manipulations complexes, comme des enchaînements de pages.
Le danger vient donc du fait que les opérations sur votre site peuvent être exécutées de manière automatisées, sans intervention de l'utilisateur. Ce sera donc le vecteur de l'attaque CSRF. Il reste maintenant à trouver un site ayant une XSS (le site victime final ou bien un autre, cela n'a pas d'importance. Piochez chez xssed pour avoir de belles listes de sites populaires), et un utilisateur ayant suffisamment de droits.
C'est exactement le problème qui a été rapporté sur GMail récemment : une fonction anodine, l'ajout de filtre, peut être scriptée. On peut donc pousser un utilisateur ayant un compte GMail à installer un filtre automatique qui transmet les messages à une autre adresse.
Lorsque vous testerez la sécurité du site, demandez-vous si vous ne pourriez pas écrire un script JavaScript pour automatiser les opérations critiques. Si c'est le cas, vous avez votre vecteur. Pour les bloquer, il faut passer par des informatiques auxquelles JavaScript n'a pas acces, comme une demande de mot de passe, des captcha, ou des technologies connexes (images, animations, confirm(), etc).
- One more reason why CSRF sucks hard
- Google GMail E-mail Hijack Technique
-
Auteur
-
Origine
