CSRF : le Cross Site Request Forgery

Les utilisateurs ne sont pas toujours au fait des dangers que représente leur navigation sur Internet. Outre le Spear phishing, le Cross Site Request Forgery est un outil privilégié des cybercriminels. Via cette méthode, les hackers peuvent, par exemple, initier des virements en ligne vers des comptes à l’étranger. Comment fonctionne donc ce mode d’escroquerie ? Et comment s’en protéger ?

Supposons qu’un utilisateur est connecté à une plateforme en ligne. Après sa connexion, l’utilisateur 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 cybercriminel : les utilisateurs connectés sont, en effet, en mesure d’exécuter des actions plus approfondies que les utilisateurs non connectés.

Explication du principe de CSRF : tandis que l’utilisateur est connecté au portail, il accède à un autre site, créé par un hacker. Là, il exécute une action quelconque en cliquant, par exemple, sur un bouton. Le hacker envoie alors une requête HTTP au portail utilisé par l’utilisateur et usurpe ainsi son identité pour exécuter une action malveillante 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 relativement facile de récupérer.

Le serveur du portail reconnaît la formulation de la requête HTTP et utilise les cookies correspondants pour confirmer que l’utilisateur (c’est-à-dire son navigateur) est encore connecté. Le serveur exécute l’action et il se peut que l’utilisateur 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 provenance de la requête. Il ne différencie donc pas les requêtes HTTP émis par le site même ou une source étrangère quelconque. L’agresseur exploite cette faiblesse du navigateur qui retransmet les requêtes sans en évaluer les conséquences.

Les trois variantes d’attaque CSRF les plus fréquentes sont les suivantes : la plus populaire est sans doute la fausse affectation d’une URL. Elle est dissimulée sur un site externe ou dans un email. Lorsque l’URL est appelée, la requête HTTP est émise. En principe, l’utilisateur peut aisément prendre note de cet URL s’il y fait très attention. Via l’ingénierie 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 construire leur propre site malveillant, certains hackers manipulent un site pré-existant via XSS et l’exploite à des fins criminelles, à l’insu de son exploitant réel. En règle générale, cette attaque implique la fausse affectation d’un site JavaScript qui exécute alors une attaque CSRF.

Lorsque le hacker réussit à enregistrer un logiciel malveillant sur l’ordinateur de la victime, une attaque Cross Site Request Forgery peut être lancée. L'agresseur peut alors directement commander l’envoi de la requête HTTP par le navigateur. Une fois des virus ou logiciels malveillants enregistrés sur l’ordinateur client, l’agresseur dispose de nombreuses autres possibilités d'attaque.

Dans notre exemple de CSRF, nous faisons référence aux opérations bancaires en ligne, car elles illustrent au mieux la portée potentielle de telles techniques d'attaque. Un utilisateur se connecte à son compte en ligne. Il y trouve un formulaire spécifique lui permettant de procéder à un virement bancaire. Lorsqu'il remplit ce formulaire et clique sur le bouton de confirmation, une requête HTTP spécifique est envoyée au serveur et le virement est effectué. L'escroc sait précisément à quoi ressemble le formulaire et comment la requête HTTP est élaborée. Il peut donc les reproduire. Les seules informations à saisir sont alors ses propres coordonné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 apparemment inoffensif 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 simplicité. L’utilisateur ne le remarque que plus tard, sur son relevé de comptes.

Autres scénarios d‘attaque :

• Réseaux sociaux : Des commentaires ou « Likes » sont publiés au nom de l’utilisateur connecté.
• Administration de site Web : Lorsqu’une victime a accès à un système dorsal, de nouveaux utilisateurs peuvent être créés à son insu ou le site peut être supprimé dans son entier.
• Achats en ligne : un hacker peut acheter des marchandises dans une boutique en ligne, à l’insu de l’utilisateur.

L’utilisateur 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éconnecter ses sessions actives de portails sécurisés, avant d’ouvrir des sites à la réputation difficile à évaluer.

L’utilisateur doit également s'assurer de l’absence de logiciel malveillant sur son appareil (PC, portable, smartphone, etc.). Lorsqu’une application d'arrière-plan espionne l’utilisateur, il est considérablement plus difficile d’éviter des CSRF. Lorsque le matériel du client est déjà infecté, d'autres techniques d’escroquerie sont également possibles.

Les exploitants de site peuvent également protéger leurs visiteurs : les agresseurs peuvent lancer des attaques Cross Site Forgery lorsqu’ils ont une connaissance précise des formulaires correspondants et des requêtes HTTP. Lorsqu'un facteur aléatoire entre en jeu, le hacker doit généralement capituler. Le site Web peut, par exemple, produire un jeton unique (une séquence de caractè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 automatiquement rejetée.

Dans le cas des banques en ligne, un processus de double authentification est prévu : avant que l’utilisateur puisse exécuter un virement, il doit saisir un numéro de transaction (TAN) non disponible 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 authentification.

En théorie, l’en-tête référant offre une première couche de protection. 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 extensions de navigateur, telles que les logiciels de blocage de fenêtres publicitaires, modifient ou suppriment l’en-tête référant. Les utilisateurs choisissant ce type de configuration ne peuvent alors plus exploiter l’offre du site.

Une mesure qui n’offre pas une protection exhaustive mais représente un premier obstacle pour l’agresseur, dans la mesure où ses sessions ne fonctionnent que sur des périodes limitées. Sur ce point, l’exploitant du site doit jauger le risque et l’impact que cette mesure peut avoir sur la convivialité d’utilisation de son site. Les portails de banques par exemple, déconnectent les utilisateurs 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, maintiennent les sessions actives pendant plusieurs jours. Dès que l'utilisateur n’est plus connecté au portail, aucune attaque CSRF n’est plus possible.