Cours de Sécurité accéléré no. 4 - CSRF

Cet article a été écrit par Damien Metzger, et publié sur le blog de PrestaShop le 30 novembre 2011.

Une faille CSRF consiste à exploiter l'identité d'un utilisateur autorisé en forçant le navigateur à envoyer une requête à son insu. Plus concrètement, si une page est protégée par un système de login / mot de passe stocké dans le cookie par exemple, il n'est pas possible d'y accéder sans vous être authentifié. Mais le marchand, qui lui est déjà authentifié, peut y accéder.

Il suffit donc pour le pirate d'envoyer le marchand sur la page de son choix, par exemple en lui envoyant un message instantané ou un mail comme on en voit souvent, tel que « Salut ! Viens voir mes nouvelles photos, tu me trouves jolie ? » accompagné d'un lien qui redirigera la victime sur http://www.maboutique.com/admin/index.php?tab=AdminCustomers&deletecustomer&id_customer=1

En théorie, ce lien permet d'effacer le client numéro 1 de la boutique « maboutique.com ». Cet exemple ne fonctionne pas avec PrestaShop car le logiciel est justement sécurisé pour éviter ce type de manipulation, mais vous comprenez le principe : il suffit de faire cliquer le marchand sur un lien qui effectue l'action souhaitée. Vous ne pouvez pas le faire vous-même, mais le marchand peut le faire à votre place sans le savoir.

Cette attaque est donc très puissante car elle ne nécessite pas directement d'avoir une faille dans la boutique. Il faut ici mettre en place une protection plus active que les protections utilisées pour les XSS ou injections.

La solution passe par l’utilisation de token de sécurité, comme vous pouvez le voir dans PrestaShop ou phpMyAdmin par exemple. Pour chaque page ou même chaque action, le développeur doit générer un hash unique à partir de données spécifiques au marchand : cumulez identifiant d’utilisateur, l'adresse web de la boutique, un "salt" généré à l’installation, l'adresse de la page et l'action souhaitée en paramètre d'une fonction sha1() pour obtenir un hash réellement complet. Ensuite, à chaque chargement de page et avant tout traitement, vous recalculez le token et vous le comparez à celui que vous aurez passé en paramètre de chaque lien. Ainsi, le pirate devra nécessairement calculer de son côté le bon sha1 – ce qui est impossible - pour exploiter cette faille.

Mais on peut très bien ne pas s'arrêter là. Par exemple, un pirate peut essayer de cumuler XSS et CSRF. En exploitant une faille XSS il peut parvenir à vous faire exécuter du code JavaScript. A l'aide de ce code JavaScript, il peut récupérer le token dans l'URL ou un token qui serait présent dans d'autres liens utilisés sur la page. C'est pourquoi la sécurité est un tout et qu'une seule faille est nécessaire pour rentrer, car une fois passée la première barrière il est beaucoup plus facile au pirate d'étendre son pouvoir.