Question sur la CSRF

Bonjour à tous.

Après une petite discutions avec un collègue à propos de la CSRF, une question nous reste un peu sans réponse:

Donc, pour résumer, si j'ai bien compris, la CSRF est une faille qui permet à l'attaquant de faire valider un script/formulaire par sa victime à son insu.

Par exemple, imaginons un panneau d'administration de news, où une action est prévue pour supprimer les news:
http://monsite.com/admin/news/delete/[ID]

l'attaquant, qui à connaissance de ce lien mais n'y a pas accès, aura pour but (via une XSS sur un site lambda, un lien par mail ou autres encore) de vous faire exécuter ce script. par exemple, imaginons que ce bout de code soit entré (dans un chat avec des XSS permanente pourquoi pas) dans un site que vous visitez souvent:

Code:

---

document.location = "http://monsite.com/admin/news/delete/151";

---

et donc, si vous allez visitez ce site, vous supprimerez la news n°151 sur votre propre site à votre insu.

Du coup, les préconisations de protection de ces failles sont plutôt simple: générer un token sur la page du formulaire/panel d'admin des news:

Code:

---

1 2 3

<?php $token = sha1(uniqid()); $_SESSION["csrf_".$token] = time()+300; ?> <input type="hidden" name="token" value="<?php echo $token;?>" />

---

dont l’existence sera vérifié avant l’exécution du script de suppression de la news, si cela n'est pas le bon, c'est que l'appel au script de suppression s'est fait sans passer par le panneau d'admin, et donc il y a un problème.

Code:

---

1 2 3

if(isset($_SESSION["csrf_".$_POST['token'])) && $_SESSION["csrf_".$_POST['token']<time()){ delete_news(); }

---

Jusque là j'ai bon ?


Maintenant la question c'est: qu'en ai-t-il si l'attaquant peut, toujours via une XSS par exemple, nous faire attirer sur la page qui génère se token avant de nous rediriger vers le script de suppression ?
Le token existera bien, donc la news sera bel et bien supprimer a notre insu, non ?

je pense notamment, dans le cas d'une xss, à quelque chose du genre:

Code:

---

1 2 3 4

window.open("http://monsite.com/admin/news"); setTimeout(function(){ window.open("http://monsite.com/admin/news/delete/151"); }, 500)

---

Bref, du coup, je ne vois pas trop l’intérêt de ce token comme protection des CSRF :/

Une petite explication ? je m'y prends mal ? ^^

Merci beaucoup,
Un dev concerné par la sécu de ses appli :D

Non puisque l'attaquant ne peut pas récupérer la valeur du token csrf et l'écrire dans le formulaire. Un csrf n'a pas de sens dans un simple lien, il faut le faire dans un formulaire: la vérification se fait en comparant les 2 valeurs dans le formulaire et en session.

Si ta ressource peut s'effacer par un simple lien, il y a un sérieux défaut de conception dans ton code. GET ne doit jamais modifier une ressource.

Ah bah oui ^^

Je n'avais pas réfléchi jusqu'au bout il faut croire;
C'est vrai que si l'attaquant fait exécuter une page à quelqu'un d'autre via du javascript, il n'est pas dans la capacité de récupérer la source html, et donc la valeur du token, simplement :)
Enfin... il y aurait bien une possibilité, dans le cas ou le cross-site serait autorisé sur tout les domaines (plus fréquent qu'on ne l'imagine sur le net ^^)... mais bon dans ce cas là, la faille de sécu se trouve à ce niveau, y'a plus vraiment de rapport avec la CSRF.


Pour ce qui est de la deuxième partie, je te comprends: il ne s'agissait que d'un exemple minimaliste fait à l’arrache pour illustrer mon problème, rien à voir avec le vrai code de mes appli ;)
Mais je te rassure, j'aurai surement fait la même remarque ^^


Enfin après, dans l'exemple d'un backend de news, il y a tout de même très souvent des liens qui permettent l'activation/désactivation de la news par un simple lien. la plupart des CMS que j'ai testé étaient fait ainsi dans mon souvenir.
Du coup, dans ce genre de cas, c'est quoi le secret pour empêcher l'attaquant de nous faire directement appelé "http://monsite.com/admin/news/disable/[id]" ? ^^
On doit forcement remplacer tout les petits boutons de désactivation par des form ? :/

Théoriquement, oui, il faut toujours intercepter le clic sur le lien et envoyer une requête form. Selon les specs HTTP, GET est une méthode sécurisée, i.e. sa seule fonction est de récupérer des informations, rien d'autre.

Si l'application en venait à utiliser des liens quand même, il faut ajouter le token sur l'url. Wordpress, qui utilise des liens pour supprimer des ressources, utilise par exemple un nonce en tant que paramètre du lien pour vérifier sa validité. Le principe est le même que le champ csrf d'un formulaire. Donc, dans ton exemple, il faudrait par exemple utiliser à la place

Code:

---

http://monsite.com/admin/news/delete/151?nonce=62ffg24f

---

Je vois :)

et bien merci pour toutes ces petites explications :)

résolu.