1.2 [Basics] Attaques CSRF : prévenir

Apprends à te défendre contre les attaques Cross-Site Request Forgery (CSRF) !

Objectifs

• Connaître les principales pratiques de défense à adopter en tant qu'utilisateur contre les CSRF
• Savoir expliquer le principe du Synchronizer Token Pattern

Une mamie qui vous veut du bien

Source : Photo by Jay Wennington on Unsplash

[Rappel : Ta grand-mère, darkMereGrand_93, amatrice de confiture de pruneaux et hacktiviste énergique, t'a envoyé un e-mail piégé que tu t'es naïvement empressé·e d'ouvrir, ce qui t'a précipité·e dans le monde fabuleux des attaques CSRF.]

Aaaah, enfin vendredi soir ! Après une dure semaine, te voilà dans l'obscurité de ton salon, un verre de limonade à la main et ton ordinateur sur les genoux. Un œil sur VisageLivre, un autre sur Gazouillement et un troisième sur ton compte bancaire (tu projettes de te commander une pizza), tu slalomes entre les onglets avec la virtuosité de l'expert·e en zone de confort. Quand soudain...

– Ne me dis pas que tu consultes tes comptes dans la même fenêtre que celle que tu utilises pour regarder des vidéos de bébés girafes ! Il va falloir qu'on ait une discussion sérieuse sur la prévention des attaques CSRF, ma petite caille digitale !

Tu te retournes lentement, très lentement... Et ta dernière gorgée de limonade, de même que la perspective d'une soirée à faire autre chose que de la cyber-sécurité, s'évapore tandis que ta grand-mère rallume la lumière au son d'un « Mais comment tu fais pour ne pas devenir aveugle, à rester dans le noir comme ça ? » familier.

Se défendre en tant qu'utilisateur

Source : Wikimedia

Connaître quelques principes de bases pour te prémunir d'une attaque CSRF te permettra de te défendre en tant qu'internaute lambda, mais aussi de protéger tes applications web si tu en es, par exemple, l'administrateur.

Consulte ces conseils sur le sujet.

Sécuriser son application web : petit rappel

Souviens-toi : lors d'une attaque CSRF, un·e pirate piège un·e utilisateur·trice pour lui faire faire une action sur un site web victime contre son gré (par exemple, réaliser un transfert d'argent ou bannir un membre). Pour que l'attaque marche :

1. L'utilisateur·trice doit être authentifié·e sur le site web en question, c'est-à-dire que son navigateur doit avoir le cookie avec les informations d'authentification de l'utilisateur pour le site victime.
2. La·la pirate amène la victime à visiter une page malveillante (par exemple, en lui promettant une galerie de photos de chatons déguisés en pilotes d'avion).
3. À partir de cette page malveillante, une requête est envoyée vers le serveur du site web victime, sans que l'utilisateur·trice s'en rende compte.
4. Comme le navigateur n'arrive pas à savoir si la requête est émise depuis une page du vrai site ou depuis une page malveillante, il fournit les informations du cookie d'authentification nécessaires au bon déroulement la requête. Et hop, l'attaque est faite !

Mmh, si seulement il y avait un moyen de savoir que la requête provient bien d'une page du vrai site, et non d'un site malveillant...

Précipite-toi à l'étape suivante pour découvrir comment les programmeurs·euses ont répondu à ce problème !

Le Synchronizer Token Pattern

Principe général

Plusieurs solutions existent pour protéger une application web des CSRF, notamment le récent SameSite, qui semble très prometteur mais n'a pas encore été adopté par tous les navigateurs.

Nous ne parlerons ici que de la solution la plus répandue (et recommandée en priorité par l'OWASP). Elle se fonde sur un pattern (c'est-à-dire une solution reconnue comme étant une bonne pratique répondant à un problème donné), le Synchronizer Token Pattern.

Cette méthode est aussi parfois appelée CSRF token, anti-CSRF token ou encore anti-forgery token.

Pour t'aider à visualiser le fonctionnement d'un CSRF token, voici une illustration :

Source : Medium, Securing Your PHP Web Application Using Synchronizer Token Pattern

Il était une fois...

Besoin d'enfoncer le clou avec une petite métaphore ? Lis l'histoire suivante (facultatif, si tu penses avoir compris tu peux passer ton chemin sans crainte).

Source : Photo by Elliott Blair on Unsplash

Imagine que tu écris régulièrement des lettres à ta grand-mère, darkMereGrand_93.

Un soir, alors que tu es passablement émeché·e par une consommation excessive de cidre doux, un individu malveillant que tu viens de rencontrer te propose la dictée suivante (chacun ses jeux à boire, après tout) : « Besoin de vitamines urgent. Peux-tu commander une cagette de myrtilles et la faire expédier au 4, rue du petit Cupidon à Arnac-la-Poste ? Bises bises. ».

Ce que tu ne sais pas, c'est que l'individu en question est un amateur de myrtilles notoire, et que son objectif réel est de se faire expédier une cagette desdits fruits par ta grand-mère. Par ailleurs, cet être démoniaque a réussi à trouver l'adresse de ta mamie. Il dispose donc de :

• l'adresse de ta grand-mère (= l'URL correspondant à la requête qu'il veut te faire faire) ;
• une lettre écrite de ta main (= le cookie d'authentification stocké dans ton navigateur).

Il pourrait ainsi envoyer cette lettre (= la requête malveillante) à ta grand-mère (= le serveur du site victime) qui, reconnaissant ton écriture (= tes informations d'authentification, issues d'un cookie), expédierait les myrtilles sans tarder. En termes de piratage, c'est tout ce qu'il faudrait pour qu'une attaque CSRF fonctionne !

Seulement, ce que ce pirate ne sait pas, c'est que ta mamie est une consultante en cyber-sécurité à la retraite, et qu'ensemble vous avez mis en place une forme de Synchronizer Token Pattern pour sécuriser votre correspondance épistolaire.

En effet, à chaque fois que tu veux écrire à ta grand-mère, tu l'appelles d'abord par téléphone pour la prévenir (oui, ça casse la magie de l'écrit, mais la sécurité avant tout !). Elle choisit alors un papier à lettres comportant un motif particulier (= le token), par exemple des chatons qui dansent (= génération du token par le serveur), dont elle se souviendra (= stockage du token côté serveur), puis elle te le fait parvenir. Ce motif est connu uniquement d'elle (puisqu'elle l'a choisi) et de toi (puisque tu l'as reçu), et change à chaque fois que tu veux lui envoyer une lettre. Ainsi :

• Si ta mamie reçoit une lettre rédigée avec ton écriture (= tes informations authentification, issues d'un cookie), mais sur un papier ordinaire (= sans le bon token), elle ignorera la lettre (= la requête sera rejetée).
• Si ta mamie reçoit une lettre rédigée avec ton écriture (= tes informations authentification, issues d'un cookie) et sur un papier comportant le bon motif secret (= avec le bon token), elle répondra à la lettre (= la requête sera traitée par le serveur).

Détaillons !

Pour consolider tout ce que tu viens de voir, consulte la documentation de l'OWASP sur le sujet (comme elle est assez détaillée, tu peux directement démarrer au paragraphe débutant par « In order to facilitate... »). Elle contient peut-être des notions que tu ne connais pas encore, comme les appels AJAX. Si c'est le cas, ne passe pas trop de temps à faire des recherches pour les comprendre : ici, l'important est que tu lises ce que tu sais déjà, mais formulé de manière plus technique dans un document qui sert de référence à la communauté des dév.

Le Synchronizer Token Pattern : en pratique

Du côté de la page web à sécuriser (c'est-à-dire du côté client), la valeur du token anti-CSRF peut être stockée de plusieurs façons, dont les deux plus connues sont :

• Un hidden field, si la page à sécuriser est un formulaire (c'est l'exemple qui est traité dans les ressources de l'étape précédente). Si tu as besoin d'une piqûre de rappel sur ce que c'est, rends-toi ici.

• Un **tag **<meta>, si la page à sécuriser est autre chose qu'un formulaire (pour plus de détails, vas voir là).

Du côté du serveur, les implémentations divergent selon la technologie utilisée, nous ne rentrerons donc pas dans les détails dans cette quête. Tu peux néanmoins voir quelques pistes d'exemples ici. N'hésite pas à chercher par toi-même pour savoir comment les menaces de CSRF sont gérées dans ta technologie de prédilection !