[Web et sécurité] Contrer les attaques XSRF

Ce tutoriel n'a absolument pas pour but d'enseigner comment attaquer un site mais d'expliquer aux webmasters de comprendre afin de mieux s'en prémunir pour la sécurité de tous.

L'attaque XSRF ou Cross-site request forgery prononcé Sea-surf est une attaque plutôt difficile à mettre en œuvre mais qui dans un certain nombre de cas s'avère extrêmement efficace. L'attaque utilise un problème de conception de l'application.

Prenons un exemple simple de à quoi peu servir ce genre d'attaque. Vous le savez, ici les modérateur et administrateur peuvent supprimer les messages sur le forum et pas vous. Le but de l'attaque XSRF est que vous nous piégiez sans qu'on s'en rende compte et que à votre guise vous puissiez supprimer des messages (même si dans les fait ce seront nous qui feront l'effacement).

Imaginons qu'on est une page delete.php qui supprime les messages. Dans cette page on fera des vérifications qu'il s'agit bien d'un modérateur ou plus avant d'accepter une suppression, chose 100% normal. Pour supprimer un message les url seront delete.php?idmessage=666. Lorsqu'un modérateur arrivera sur cette page alors le message 666 sera supprimé. Parfait ! Bien sûr ce lien ne sera affiché qu'au modérateur, bref vous vous dite que ce code est sécurisé, il y en a une double, 1 il faut connaitre l'url, 2 on vérifie qu'il s'agit bien d'un modérateur.

Sauf que sauf que ! C'est mal connaitre le protocole http ! Vous savez le truc http:// .... je rigole ! Ajoutez donc dans le forum ou sur n'importe qu'elle page web <img src="http://lesitequonattaque/delete.php?idmessage=666" /> et maintenant envoyer cette page à un administrateur. Une alerte de modération, un email n'importe quoi. Que se passe-t-il ? Le modérateur charge la page, charge les images de la page ce qui a pour effet de faire une requête http sur delete.php?idmessage=666 et si ce modérateur était connecté sur le forum, ni vu ni connu il a supprimé le message 666 !

Mais alors comment contrer ce genre d'attaque ?

Il y a 2 grandes solutions, la première est de demander confirmation à l'utilisateur. En l'occurence, le navigateur ne trouve pas une image comme il aurait du, il n'affiche donc rien mais si l'utilisateur charge la page correctement alors il n'à qu'à cliquer sur "valider l'action" et là alors le message est bien supprimé. C'est par contre relativement contraignent pour l'utilisateur.

La seconde solution est de respecter un peu plus le protocole HTTP. Il existe 5 grandes actions dans le protocole HTTP, HEAD, GET POST, PUT et DELETE. Les navigateurs n'implémentent actuellement que 2, même si avec HTML5 cela pourrait changer, mais comme on ne sait pas encore à quoi va ressembler HTML5 ... Bref on a GET et POST. GET siginifie récupérer du contenu et POST signifie modifier du contenu. (PUT correspond à créer, et DELETE effacer) En l'occurence notre delete.php?idmessage=666 correspond à une modification dans notre application web. Lorsque l'utilisateur clique sur le message il devrait donc naturellement effectuer une requête de type POST.

Le navigateur web lui connait HTTP, il sait donc que lors de l'exemple de l'image, il va récupérer une image et donc faire une requête de type .... GET ! Un navigateur ne fera jamais 2 requêtes POST sans vraiment que l'utilisateur en soit averti (sauf via Javascript par exemple dans le cas d'une attaque XSS).

La solution consiste donc à vérifier que la variable idmessage est bien dans le cas de PHP dans la variable $_POST et non dans $_GET. Il faut en revanche modifier le simple clic par un formulaire qui sera valider, certainement en javascript avec un champ caché qui sera idmessage.

Pour aller plus loin

Hypertext Transfer Protocol
Cross-site requesto forgery

Licence

Ce document est placé sous Licence Creative Commons Paternité 2.0