CSRF : le Cross Site Request Forgery

Les uti­li­sa­teurs ne sont pas toujours au fait des dangers que re­pré­sente leur na­vi­ga­tion sur Internet. Outre le Spear phishing, le Cross Site Request Forgery est un outil pri­vi­lé­gié des cy­ber­cri­mi­nels. Via cette méthode, les hackers peuvent, par exemple, initier des virements en ligne vers des comptes à l’étranger. Comment fonc­tionne donc ce mode d’es­cro­que­rie ? Et comment s’en protéger ?

Supposons qu’un uti­li­sa­teur est connecté à une pla­te­forme en ligne. Après sa connexion, l’uti­li­sa­teur rester connecté pendant toute la durée de la session (cette période peut varier), sans devoir saisir à nouveau son mot de passe. C’est ici l’occasion idéale pour un cy­ber­cri­mi­nel : les uti­li­sa­teurs connectés sont, en effet, en mesure d’exécuter des actions plus ap­pro­fon­dies que les uti­li­sa­teurs non connectés.

Ex­pli­ca­tion du principe de CSRF : tandis que l’uti­li­sa­teur est connecté au portail, il accède à un autre site, créé par un hacker. Là, il exécute une action quel­conque en cliquant, par exemple, sur un bouton. Le hacker envoie alors une requête HTTP au portail utilisé par l’uti­li­sa­teur et usurpe ainsi son identité pour exécuter une action mal­veil­lante pendant que sa session est encore active. Pour ce faire, le hacker n'a besoin que de la bonne requête HTTP, un élément qu'il lui est re­la­ti­ve­ment facile de récupérer.

Le serveur du portail reconnaît la for­mu­la­tion de la requête HTTP et utilise les cookies cor­res­pon­dants pour confirmer que l’uti­li­sa­teur (c’est-à-dire son na­vi­ga­teur) est encore connecté. Le serveur exécute l’action et il se peut que l’uti­li­sa­teur ne remarque pas qu’une action a été exécutée en son nom.

L’attaque CSRF aboutit car le serveur de réception ne vérifie pas la pro­ve­nance de la requête. Il ne dif­fé­ren­cie donc pas les requêtes HTTP émis par le site même ou une source étrangère quel­conque. L’agresseur exploite cette faiblesse du na­vi­ga­teur qui re­trans­met les requêtes sans en évaluer les con­sé­quences.

Les trois variantes d’attaque CSRF les plus fré­quentes sont les suivantes : la plus populaire est sans doute la fausse af­fec­ta­tion d’une URL. Elle est dis­si­mu­lée sur un site externe ou dans un email. Lorsque l’URL est appelée, la requête HTTP est émise. En principe, l’uti­li­sa­teur peut aisément prendre note de cet URL s’il y fait très attention. Via l’in­gé­nie­rie sociale et le spoofing d’URL, l’origine de l’URL peut toutefois être masquée.

Il existe également des points de référence à ce que l’on appelle le Cross Site Scripting (XSS) : au lieu de cons­truire leur propre site mal­veil­lant, certains hackers ma­ni­pu­lent un site pré-existant via XSS et l’exploite à des fins cri­mi­nelles, à l’insu de son ex­ploi­tant réel. En règle générale, cette attaque implique la fausse af­fec­ta­tion d’un site Ja­vaS­cript qui exécute alors une attaque CSRF.

Lorsque le hacker réussit à en­re­gis­trer un logiciel mal­veil­lant sur l’or­di­na­teur de la victime, une attaque Cross Site Request Forgery peut être lancée. L'agres­seur peut alors di­rec­te­ment commander l’envoi de la requête HTTP par le na­vi­ga­teur. Une fois des virus ou logiciels mal­veil­lants en­re­gis­trés sur l’or­di­na­teur client, l’agresseur dispose de nom­breuses autres pos­si­bi­li­tés d'attaque.

Dans notre exemple de CSRF, nous faisons référence aux opé­ra­tions bancaires en ligne, car elles il­lustrent au mieux la portée po­ten­tielle de telles tech­niques d'attaque. Un uti­li­sa­teur se connecte à son compte en ligne. Il y trouve un for­mu­laire spé­ci­fique lui per­met­tant de procéder à un virement bancaire. Lorsqu'il remplit ce for­mu­laire et clique sur le bouton de con­fir­ma­tion, une requête HTTP spé­ci­fique est envoyée au serveur et le virement est effectué. L'escroc sait pré­ci­sé­ment à quoi ressemble le for­mu­laire et comment la requête HTTP est élaborée. Il peut donc les re­pro­duire. Les seules in­for­ma­tions à saisir sont alors ses propres coor­don­nées bancaires et un montant à virer.

Le hacker peut ensuite créer un site Web (ou envoyer un email) faisant appel aux intérêts du client bancaire. Ce dernier est alors invité à cliquer sur un lien ap­pa­rem­ment inof­fen­sif pour activer la requête HTTP falsifiée. Celle-ci est ensuite envoyée à la banque qui exécute l’action demandée par le hacker. La session est encore active et la requête correcte : Le serveur n’a aucune raison de ne pas exécuter l’action. L'argent est donc transféré en toute sim­pli­cité. L’uti­li­sa­teur ne le remarque que plus tard, sur son relevé de comptes.

Autres scénarios d‘attaque :

• Réseaux sociaux : Des com­men­taires ou « Likes » sont publiés au nom de l’uti­li­sa­teur connecté.
• Ad­mi­nis­tra­tion de site Web : Lorsqu’une victime a accès à un système dorsal, de nouveaux uti­li­sa­teurs peuvent être créés à son insu ou le site peut être supprimé dans son entier.
• Achats en ligne : un hacker peut acheter des mar­chan­dises dans une boutique en ligne, à l’insu de l’uti­li­sa­teur.

L’uti­li­sa­teur doit faire preuve de prudence : en évitant de naviguer sur des sites douteux ou d’ouvrir des e-mails sans réfléchir, il est possible de déjouer de telles attaques. Pour se protéger contre les CSRF, il est important de dé­con­nec­ter ses sessions actives de portails sécurisés, avant d’ouvrir des sites à la ré­pu­ta­tion difficile à évaluer.

L’uti­li­sa­teur doit également s'assurer de l’absence de logiciel mal­veil­lant sur son appareil (PC, portable, smart­phone, etc.). Lorsqu’une ap­pli­ca­tion d'arrière-plan espionne l’uti­li­sa­teur, il est con­si­dé­ra­ble­ment plus difficile d’éviter des CSRF. Lorsque le matériel du client est déjà infecté, d'autres tech­niques d’es­cro­que­rie sont également possibles.

Les ex­ploi­tants de site peuvent également protéger leurs visiteurs : les agres­seurs peuvent lancer des attaques Cross Site Forgery lorsqu’ils ont une con­nais­sance précise des for­mu­laires cor­res­pon­dants et des requêtes HTTP. Lorsqu'un facteur aléatoire entre en jeu, le hacker doit gé­né­ra­le­ment capituler. Le site Web peut, par exemple, produire un jeton unique (une séquence de ca­rac­tères aléatoire) et alors l’insérer dans la requête HTTP. Lorsque le serveur reçoit une requête ne contenant aucun jeton valide (ou un jeton invalide), la requête est alors au­to­ma­ti­que­ment rejetée.

Dans le cas des banques en ligne, un processus de double au­then­ti­fi­ca­tion est prévu : avant que l’uti­li­sa­teur puisse exécuter un virement, il doit saisir un numéro de tran­sac­tion (TAN) non dis­po­nible sur le site. Cette technique protège des CSRF, mais aussi d'autres attaques. En effet, même si un hacker parvenait à voler vos données d'accès, il ne pourrait pas exécuter de virement sans cette seconde au­then­ti­fi­ca­tion.

En théorie, l’en-tête référant offre une première couche de pro­tec­tion. Cette partie de la requête HTTP indique d'où provient la requête. Les sites Web peuvent ainsi filtrer les sources inconnues. Par le passé, l’en-tête référant a toutefois révélé des failles. Les ex­ten­sions de na­vi­ga­teur, telles que les logiciels de blocage de fenêtres pu­bli­ci­taires, modifient ou sup­pri­ment l’en-tête référant. Les uti­li­sa­teurs choi­sis­sant ce type de con­fi­gu­ra­tion ne peuvent alors plus exploiter l’offre du site.

Une mesure qui n’offre pas une pro­tec­tion ex­haus­tive mais re­pré­sente un premier obstacle pour l’agresseur, dans la mesure où ses sessions ne fonc­tion­nent que sur des périodes limitées. Sur ce point, l’ex­ploi­tant du site doit jauger le risque et l’impact que cette mesure peut avoir sur la con­vi­via­lité d’uti­li­sa­tion de son site. Les portails de banques par exemple, dé­con­nec­tent les uti­li­sa­teurs en l’absence de saisie pendant quelques minutes. D’autres sites (tels que de nombreux portails de réseaux sociaux), qui traitent des données moins sensibles, main­tien­nent les sessions actives pendant plusieurs jours. Dès que l'uti­li­sa­teur n’est plus connecté au portail, aucune attaque CSRF n’est plus possible.