Il semble que je comprends mal le CSRF ?

Question

Après avoir lu de nombreux documents concernant CSRF, je suis encore un peu confus. J'espère donc que quelqu'un pourra m'expliquer :

1. Imaginons que j'ai une page de profil qui est réservée aux utilisateurs authentifiés uniquement, disons abc.com/profile qui affiche toutes mes informations privées. Si je suis connecté, puis vais sur un "mauvais" site, ce site peut-il d'une manière ou d'une autre obtenir et analyser ma page de profil ? (J'ai fait un petit test en ouvrant la console firebug sur un site différent, puis en demandant ma page de profil, et il semble qu'au moins je puisse voir tout le contenu dans la "réponse" de l'onglet "Net", mais je n'ai pas encore réussi à obtenir ce contenu et à l'analyser. Mais peut-être est-ce possible ?)

2. Imaginons maintenant que j'ai sur ma page de profil un formulaire, qui bien sûr a un jeton CSRF. Maintenant, si un attaquant pouvait obtenir ma page de profil, il pourrait simplement analyser ce contenu, obtenir le jeton puis soumettre un faux formulaire ?

3. Imaginons maintenant que les points 1 et 2 sont corrects, que devrais-je faire pour empêcher de tels cas de se produire ?

Answer 1

Vos points ne sont pas tout à fait corrects... Mais prenons ce scénario.

Exemple d'Attaque

---

Imaginez qu'un utilisateur est connecté à La Banque Officielle du Pays Faux - GoodBank.com et a un solde de 1 000 000 d'or.

Sur MaliciousSite.com, il y a une ou un autre JavaScript générique qui vous oblige à faire une requête à GoodBank.com.

L'image a une src de http://www.goodbank.com/account/transfer.php?amount=10000&sentTo=malicioususer.

---

Maintenant ce site a fait une requête sous votre compte utilisateur et vous a obligé à invoquer une page que vous n'auriez pas consultée autrement.

Pensez-vous que vous pouvez vous protéger en n'utilisant que POST, mais ceux-ci ne sont pas non plus sécurisés. La bonne méthode est d'utiliser des jetons CSRF dans vos formulaires, et lorsque vous soumettez un formulaire, vous devez vérifier que le jeton CSRF que vous recevez est le même que celui qui a été émis.

Ne pas utiliser ces mesures pour vous protéger :

• Cookies Secrets
• Accepter uniquement les requêtes POST
• Formulaires multi-pages
• Réécriture d'URL

Utilisez plutôt un jeton comme ceci :

  …

Consultez ici pour une excellente explication : CSRF Cheat Sheet

Answer 2

Votre premier point n'est pas correct.
Vous ne pouvez pas lire le contenu d'un domaine différent sur le client.

Par conséquent, un site hostile ne peut pas lire le jeton CSRF.

Vous pouvez envoyer des requêtes à un domaine différent (c'est ce que font les attaques CSRF), mais vous ne pouvez pas lire les réponses.

Answer 3

Cela peut ne pas être directement lié à la question posée mais il est nécessaire de souligner que les attaques de type cross site scripting peuvent ouvrir la voie au CSRF. Même les solutions basées sur les jetons utilisées pour prévenir le CSRF peuvent être compromises par le XSS.

Prenons le scénario suivant.

Formulaire utilisé pour mettre à jour les informations de l'utilisateur.

...
var userID=getUserId();// méthode faisant un appel AJAX pour obtenir l'identifiant de l'utilisateur
...

...

    ...

En supposant que l'identifiant de l'utilisateur est unique et ne peut pas être deviné facilement, nous pouvons empêcher le CRSF sans jeton. (La requête de l'attaquant ne pourra pas avoir le bon identifiant utilisateur).

Mais si l'attaquant peut lire la valeur de userID en utilisant une attaque XSS, il pourra alors fabriquer la requête falsifiée pour inclure le bon identifiant utilisateur.

Bien que le XSS ne soit pas nécessaire pour les attaques CSRF, il les facilitera.

Vérifiez les ressources suivantes.

Cross-Site Request Forgery (CSRF)-OWASP

Cross-site Scripting (XSS)-OWASP