Contrefaçon de requête intersite (CSRF)

Qu’est-ce que la falsification de requêtes intersites ?

La falsification de requêtes intersites ( CSRF ) est une vulnérabilité Web qui permet à un pirate malveillant de tromper la victime en soumettant une requête qui permet à l’attaquant d’effectuer des actions de changement d’état au nom de la victime. La falsification de requêtes intersites est également appelée XSRF , sea surf , session riding ou one-click attack .

Gravité:		grave dans de rares circonstances
Prévalence:		découvert souvent
Portée:		applications web avec authentification
Impact technique :		l’attaquant déclenche des actions non autorisées
Conséquences dans le pire des cas :		dépendent des capacités de l’application
Solution rapide:		utiliser des jetons anti-CSRF

Comment fonctionne la falsification de requêtes intersites ?

La plupart des applications Web nécessitent une authentification et certains utilisateurs authentifiés sont capables d’effectuer des actions très sensibles. L’authentification dans les applications Web est souvent effectuée en fonction des sessions utilisateur. Après vous être authentifié, votre navigateur stocke un cookie de session sur votre ordinateur et l’envoie avec chaque demande que vous faites à cette application Web. Plus rarement, les applications peuvent également utiliser NTLM ou Basic Auth pour l’authentification au lieu des cookies de session, ou même reconnaître les utilisateurs en fonction de leur adresse IP.

Lorsque vous utilisez une application, de nombreuses requêtes HTTP envoyées de votre navigateur à l’application sont le résultat de vos actions explicites, par exemple lorsque vous saisissez une URL dans la barre d’adresse ou cliquez sur un lien. Cependant, d’autres requêtes HTTP sont envoyées implicitement par votre navigateur lorsqu’il traite le code inclus sur la page Web actuelle. Par exemple, si la page inclut une image, l’image sera récupérée par une requête HTTP distincte.

Ces demandes implicites peuvent également être dirigées vers des domaines qui n’ont rien à voir avec l’emplacement de la page que vous consultez. La chose cruciale dans de tels cas est que les demandes aux deux emplacements proviennent du même navigateur, donc votre méthode d’authentification actuelle (qu’il s’agisse d’un cookie de session ou d’une autre méthode) s’applique aux deux emplacements. Ainsi, si votre navigateur ouvre testcycuri.com et récupère une image de example.com , créant ainsi une session utilisateur sur example.com , l’ application Web example.com vous traitera comme un utilisateur authentifié (même si vous avez initialement ouvert testcycuri.com, et non exemple.com ).

Combinés, ces deux comportements peuvent être exploités pour effectuer des attaques de falsification de requête intersite de la manière suivante :

1. La victime est authentifiée dans l’application Web cible (telle que example.com ).
2. L’attaquant utilise l’ingénierie sociale pour inciter la victime à visiter un site Web malveillant (par exemple, testcycuri.com ).
3. La page Web malveillante inclut du code (tel qu’une balise d’image) qui amène le navigateur de la victime à envoyer une demande implicite à la cible (telle que example.com ).
4. La demande malveillante amène la cible à effectuer des actions qui n’étaient pas prévues par l’utilisateur. Les conséquences varient selon l’application.

Notez que CSRF avait sa propre catégorie distincte dans le Top 10 OWASP (par exemple, A5:2013 ). Cependant, avec le développement d’AppSec plus efficaces et donc l’impact réduit de ces vulnérabilités, l’OWASP a décidé depuis 2017 de fusionner CSRF dans une autre catégorie plus générique.

Types de vulnérabilités de falsification de requêtes intersites

Les vulnérabilités CSRF peuvent être basées sur des requêtes GET ou POST.

Dans le cas d’un CSRF basé sur des requêtes GET, l’attaquant peut simplement utiliser une balise d’image (ou toute autre balise permettant les requêtes intersites) sur une page malveillante :

<img src="http://example.com/bank.php/?action=transfer&target=attacker_account">

Lorsque l’utilisateur visite la page avec la balise d’image ci-dessus (par exemple, après avoir cliqué sur un lien malveillant), le navigateur de l’utilisateur essaie d’ouvrir l’image mais envoie à la place une requête GET au site ciblé, effectuant ainsi une action malveillante alors qu’il est connecté au compte de l’utilisateur. En supposant que l’utilisateur est authentifié sur example.com , l’application Web ne pourra pas faire la différence entre une requête utilisateur légitime et une requête malveillante, car elles sont toutes deux envoyées depuis le même navigateur.

Dans le cas de CSRF basé sur des requêtes POST, l’attaquant doit travailler un peu plus dur. Le moyen le plus simple d’effectuer une telle attaque consiste à forcer le navigateur de l’utilisateur à soumettre automatiquement un formulaire en utilisant JavaScript :

<body onload="document.csrf.submit()">
<form action="http://example.com/bank.php" method="POST" name="csrf">
    <input type="hidden" name="action" value="transfer">
    <input type="hidden" name="target" value="attacker_account">
form>

L’ onloadargument de la balise obligera le navigateur à soumettre le formulaire dès que l’utilisateur ouvrira la page malveillante.

Exemple d’attaque par falsification de requête intersite

Le développeur d’une application commerciale financière crée une fonction qui permet aux utilisateurs de définir l’adresse e-mail qu’ils souhaitent utiliser pour les rapports financiers quotidiens de l’application. Pour définir ou modifier l’adresse e-mail, un utilisateur authentifié doit remplir un formulaire HTML sur la page http://example.com/set_email.php :

<form action="/set_email.php" method="post" id="set_email">
    <label for="email">Enter the email address to receive reports:label>
    <input type="email" id="email" name="email">
    <button type="submit" form="submit" value="submit">Set emailbutton>    
form>

L’attaquant crée une page illicite http://example.attacker/exploit.html avec le contenu suivant :

<body onload=document.email.submit()>
    <form action="http://example.com/set_email.php" method="post" name="email">
        <input type="hidden" id="email" value="[email protected]">
    form>
body>

Ensuite, l’attaquant crée un e-mail de phishing et l’envoie à un utilisateur de l’application financière, incitant l’utilisateur à visiter http://example.attacker/set_email.html . En supposant que l’utilisateur est déjà connecté à l’application sur example.com , l’application recevra la demande falsifiée et modifiera l’e-mail de rapport en [email protected] . En conséquence, l’attaquant recevra quotidiennement des rapports sensibles sur les opérations financières de l’entreprise.

Conséquences potentielles d’une attaque par falsification de requête intersite

Les vulnérabilités de falsification de requêtes intersites sont considérées comme de gravité moyenne pour plusieurs raisons :

• Dans ce type d’attaque, l’attaquant ne reçoit jamais la réponse HTTP et ne peut donc pas utiliser cette technique pour lire/accéder directement aux informations sensibles. Ils n’ont même pas accès à la valeur du cookie de session qui est envoyée avec la requête malveillante.
• L’attaque est limitée par la fonctionnalité de l’application Web ou, plus précisément, par ce que l’application permet à l’utilisateur actuel de faire à l’aide d’une demande de changement d’état. Par exemple, si vous disposez d’un système de tickets et que l’utilisateur actuel ne peut que créer et résoudre des problèmes, le maximum qu’un attaquant peut réaliser avec CSRF est d’effacer la file d’attente des tickets. Ils ne pourront pas, par exemple, obtenir les informations d’identification de l’administrateur.
• Ce type d’attaque est plus efficace lorsqu’il vise une personne spécifique ou un petit groupe de personnes disposant de privilèges élevés. Contrairement au cross-site scripting (XSS) , cela n’a souvent aucun sens d’envoyer une charge utile CSRF malveillante à un grand nombre de victimes aléatoires. CSRF est généralement soigneusement préparé pour tirer parti d’un utilisateur spécifique dans l’entreprise, tel que le PDG, l’administrateur ou un employé du service financier.

Exemples de vulnérabilités connues de falsification de requêtes intersites

En raison de la nature de CSRF, il n’y a pas de failles majeures connues causées par des attaques CSRF réussies. Cependant, par le passé, plusieurs applications Web populaires se sont révélées vulnérables à la falsification de requêtes intersites et auraient pu être utilisées dans des attaques ciblées :

• Netflix : En 2006, alors que Netflix était encore un service de location de DVD, il s’est avéré qu’il présentait une vulnérabilité CSRF qui pouvait permettre à un attaquant de modifier les informations d’identification et de prendre complètement le contrôle d’un compte.
• ING : En 2008, des chercheurs ont découvert des vulnérabilités CSRF dans ingdirect.com qui pourraient permettre à un attaquant d’ouvrir des comptes bancaires au nom de la victime et de transférer des fonds depuis le compte de la victime.
• WordPress : En 2020, des chercheurs ont découvert que 25 plugins WordPress populaires présentaient des vulnérabilités CSRF .

Ce ne sont que quelques exemples parmi tant d’autres et bien que nous ne soyons pas au courant des conséquences désastreuses de ces vulnérabilités, il est possible qu’elles aient été utilisées pour des attaques ciblées individuellement qui n’ont tout simplement jamais été diffusées dans les médias.

Comment détecter les vulnérabilités de falsification des requêtes intersites ?

La meilleure façon de détecter les vulnérabilités CSRF varie selon qu’elles sont déjà connues ou inconnues.

• Si vous utilisez uniquement des applications Web commerciales ou open source et que vous ne développez pas vos propres applications Web, il peut suffire d’identifier la version exacte de l’application que vous utilisez. Si la version identifiée est sensible au CSRF, vous pouvez supposer que votre site Web est vulnérable. Vous pouvez identifier la version manuellement ou utiliser un outil de sécurité approprié, tel qu’une solution d’analyse de la composition logicielle (SCA) .Si vous développez vos propres applications Web ou souhaitez avoir la possibilité de trouver des vulnérabilités CSRF jusque-là inconnues (jours zéro) dans des applications connues, vous devez être en mesure d’exploiter avec succès la vulnérabilité CSRF pour être certain qu’elle existe. Cela nécessite soit d’effectuer des tests d’intrusion manuels avec l’aide de chercheurs en sécurité, soit d’utiliser un outil de test de sécurité (scanner) qui peut utiliser l’automatisation pour exploiter les vulnérabilités Web. 

Comment prévenir les vulnérabilités de falsification des requêtes intersites dans les applications Web ?

La principale méthode de protection contre les attaques CSRF consiste à créer un moyen pour l’application Web de différencier les demandes légitimes (faites au nom de cette application) des demandes potentiellement malveillantes (envoyées par l’application sous influence extérieure). Les deux techniques suivantes sont les plus efficaces et les plus largement utilisées.

Jetons anti-CSRF

Cette technique de protection est basée sur l’envoi d’un jeton spécial avec chaque demande légitime et sur la validation constante de ce jeton lors de la réception des demandes. Ce jeton anti-CSRF , parfois appelé jeton de synchronisation , est généré côté serveur et les attaquants n’ont aucun moyen de connaître sa valeur correcte – il n’est connu que de l’application Web et du navigateur. Les requêtes envoyées en tant que tentatives d’attaque CSRF n’auront pas de jeton valide, ce qui permet à l’application de les ignorer comme non valides, de les enregistrer comme des tentatives d’attaque ou même de déclencher une alarme.

Une fois que vous avez généré un jeton anti-CSRF, vous pouvez l’inclure dans un champ de formulaire masqué ou l’ajouter automatiquement dans un en-tête spécial pour chaque demande. Notez que les jetons anti-CSRF doivent être utilisés non seulement pour chaque formulaire dans la zone authentifiée de l’application Web, mais également pour les formulaires de connexion non authentifiés, les API et les requêtes AJAX ( ) XMLHttpRequest.

Il existe de nombreuses bibliothèques disponibles pour générer et vérifier des jetons anti-CSRF en toute sécurité à l’aide de techniques cryptographiques, par exemple, Paragonie anti-CSRF pour PHP et GDS anti-CSRF pour Java . Nous vous recommandons d’utiliser ces bibliothèques au lieu d’essayer de créer votre propre code, qui serait plus sujet aux erreurs et plus difficile à maintenir.

Notez également que bien que de nombreux frameworks de développement modernes aient déjà des jetons de synchronisation intégrés, leur protection CSRF est souvent limitée aux méthodes HTTP conçues pour les demandes de changement d’état. Cela signifie que les requêtes GET ne sont généralement pas couvertes. Par conséquent, si un développeur crée des fonctions de changement d’état qui tirent leur entrée des requêtes GET, ce qui est une très mauvaise pratique de programmation, ces requêtes ne seront pas couvertes par la protection CSRF intégrée.

Cookies du même site

Un autre moyen très efficace de différencier les requêtes légitimes des requêtes potentiellement nuisibles consiste à examiner l’origine de la requête. Vous pouvez supposer en toute sécurité que si la demande provient du même domaine/site, elle est très probablement légitime. S’il provient d’un domaine externe, il pourrait être dangereux. Pour profiter de cette méthode, vous pouvez utiliser un indicateur de sécurité de cookie spécifique .

Les navigateurs modernes prennent en charge  SameSiteattribut cookie, que vous pouvez utiliser lors de la configuration de vos cookies de session. Cela peut avoir l’un des trois paramètres suivants :

• Lax: Le navigateur n’envoie pas de cookies pour les sous-requêtes intersites, par exemple, pour charger des images ou des cadres dans un site tiers, mais envoie des cookies lorsqu’un utilisateur suit un lien.
• Strict: Le navigateur envoie des cookies uniquement dans un contexte de première partie et ne les envoie pas du tout avec des demandes initiées par des sites Web tiers.
• None: Le navigateur envoie des cookies dans tous les contextes, mais vous devez également définir Secureattribut ou le navigateur bloquera le cookie.

Bien que la plupart des navigateurs modernes définissent l’ SameSiteattribut Laxpar défaut pour tous les cookies, nous vous recommandons de le définir manuellement dans votre application Web (sur Laxou Strict, selon que vous avez besoin ou non de sous-requêtes intersites). C’est au cas où vous auriez des utilisateurs avec des versions de navigateur plus anciennes définies SameSitepar Nonedéfaut.

Malheureusement, s’il s’agit de la seule méthode que vous utilisez pour protéger vos utilisateurs contre CSRF, un petit nombre d’utilisateurs avec des navigateurs hérités tels qu’Internet Explorer qui ne prennent pas du tout en charge les cookies SameSite resteront vulnérables aux attaques CSRF.

Autres techniques de protection

Bien que les jetons de synchronisation et les cookies SameSite soient considérés comme les meilleures méthodes de protection CSRF, il existe également d’autres moyens de différencier les demandes légitimes des demandes potentiellement malveillantes. Certains développeurs utiliseront, par exemple, l’ en-tête de référence pour repérer cette différence. D’autres tentent de mettre en place une protection basée sur des mécanismes tels que la politique de même origine , qui est inefficace contre CSRF. 

Bien que des méthodes telles que la détection de référent puissent être efficaces, elles ne sont pas aussi infaillibles que les jetons anti-CSRF, nous ne recommandons donc pas d’utiliser des méthodes autres que les jetons de synchronisation et les cookies SameSite, de préférence ensemble.

Comment atténuer les attaques de falsification de requêtes intersites ?

La meilleure façon d’atténuer les attaques CSRF est de s’assurer que tous les utilisateurs de votre entreprise utilisent des navigateurs Web modernes et entièrement mis à jour qui prennent en charge les cookies SameSite. Cela permet à vos applications Web d’utiliser les cookies SameSite comme protection CSRF principale et vos développeurs n’ont pas à implémenter de protections dans le code de l’application Web (car tous les cookies sont définis par Laxdéfaut).

Vous pouvez appliquer une atténuation en désactivant l’accès à vos applications Web pour les navigateurs qui ne prennent pas en charge les cookies SameSite. Cependant, cette méthode pourrait avoir un impact négatif sur vos utilisateurs (par exemple, elle bloquera tous les utilisateurs d’Internet Explorer) et doit donc être introduite avec prudence.