Vulnérabilités du web : CSRF

Le partage, c’est bien quand c’est utile :

Aussi appelée XSRF pour Cross-Site Request Forgery, cette faille de sécurité des applications web est apparentée à la famille des failles XSS puisqu’elle cible également l’utilisateur. Comme son nom l’indique, elle permet de pousser le visiteur à effectuer des requêtes depuis son navigateur.

Depuis le site victime

Une requête peut facilement être envoyée automatiquement lors du chargement de la page. C’est le cas par exemple de toutes les images, feuilles de style CSS ou encore des scripts JavaScript. Bien que dans ce dernier cas, il serait peut-être plus intéressant d’inclure un script de votre cru si cela est possible.

Imaginons un site communautaire où vous pouvez inclure des images sur votre profil. De plus, il existe un fichier dans le répertoire admin/ se nommant edit_edito.php utilisant la variable $_GET[‘new’]. Vous ne pouvez pas directement changer l’édito pour, par exemple, profiter d’un manque de vérification sur ce contenu pour exploiter une faille XSS car vous n’avez pas les droits administrateur.

Il reste possible d’effectuer cette requête avec les droits requis. Il suffit d’utiliser le navigateur d’un administrateur logué. Pour ce faire, on va exploiter une faille CSRF. En incluant une image dont l’URL est http://example.com/admin/edit_edito.php?new=nouvel%20édito sur notre profil et en signalant son profil comme abus (par exemple), on pourrait pousser un administrateur à visiter notre profil. Son navigateur enverrait alors notre requête et changera alors l’édito avec notre nouveau contenu.

On peut également très bien imaginer une exploitation à partir d’un simple lien mais il faudra alors que l’utilisateur clique sur ce lien. En effet, rendre automatique le clic sur un lien nécessite soit du JavaScript auquel cas une faille XSS pourrait être exploitée directement ou via des techniques de ClickJacking.

Cette attaque est, comme on peut le voir, extrêmement simple. La difficulté résidant plutôt dans la sécurisation de celle-ci comme on va le voir plus loin.

Depuis un site tierce

On l’a vu dans l’exemple précédent, on ne peut dans le plupart des cas ne lancer que des requêtes GET depuis le site victime. Pourtant, la majeure partie des applications web sont faites pour recevoir des requêtes POST quand il s’agit de changer des données. (Du moins, les applications web bien faites.) Il est néanmoins possible de créer un formulaire sur un autre site et de l’envoyer automatiquement avec un petit bout de code en JavaScript. Il devient alors possible d’envoyer des requêtes POST vers n’importe quel site victime en faisant visiter la page par les personnes ayant plus de droits sur le site que le pirate.

Se protéger

Protéger son site contre les attaques externes et assez simple, il suffira de vérifier l’en-tête Referer du paquet HTTP. En PHP, cette valeur est stockée dans $_SERVER[‘HTTP_REFERER’]. Ca ne protège pourtant pas des attaques internes ou le référant sera correct.

On peut également penser à obliger les requêtes POST pour toute modification des données pour se protéger des attaques internes. Encore une fois, ça ne sécurise que partiellement l’application.

Combiner les deux suppose que forger des requêtes POST depuis le site (en interne) n’est pas possible. Ce n’est pas toujours vrai et ce serait une erreur de partir du principe que cela fonctionne.

Finalement, une méthode permettant de bloquer ces attaques consiste à vérifier la présence d’un token à la réception des requêtes POST reçues. Ce token devra être donné à l’utilisateur dans les données du formulaire (sous la forme d’un <input type= »hidden » name= »csrf_token » value= »TOKEN » />) et généré aléatoirement à chaque impression du formulaire.

Le partage, c’est bien quand c’est utile :