La falsification de requêtes intersites (également connue sous le nom de CSRF - Cross site request forgery) est une vulnérabilité de la sécurité du Web qui permet à un attaquant d'inciter les utilisateurs à effectuer des actions qu'ils n'ont pas l'intention de réaliser. Elle permet à un attaquant de contourner en partie la politique de la même origine, qui est conçue pour empêcher différents sites Web d'interférer les uns avec les autres.
Comment fonctionne le Cross-Site Request Forgery ?
L'objectif d'un attaquant pour réaliser une attaque CSRF est de forcer l'utilisateur à soumettre une demande de changement d'état. Voici quelques exemples :
- Soumettre ou supprimer un enregistrement
- Soumettre une transaction
- Acheter un produit
- Changer des mots de passe.
- Envoyer un message.
Les plateformes d'ingénierie sociale sont souvent utilisées par les attaquants pour lancer une attaque CSRF. La victime est ainsi incitée à cliquer sur une URL qui contient une requête non autorisée et malicieusement conçue pour une application Web particulière. Le navigateur de l'utilisateur envoie alors cette requête malicieusement élaborée à une application Web ciblée. La demande comprend également toute information d'identification liée au site Web en question (par exemple, les cookies de session de l'utilisateur). Si l'utilisateur est dans une session active avec une application Web ciblée, l'application traite cette nouvelle demande comme une demande autorisée soumise par l'utilisateur. Ainsi, l'attaquant réussit à exploiter la vulnérabilité CSRF de l'application Web.
Une attaque CSRF vise les applications Web qui ne parviennent pas à faire la différence entre les demandes valides et les demandes falsifiées contrôlées par l'attaquant.
Comment délivrer un exploit CSRF ?
Les mécanismes de diffusion des attaques de type cross-site request forgery sont essentiellement les mêmes que pour le XSS (Scripts intersites réfléchis). En général, l'attaquant place le code HTML malveillant sur un site web qu'il contrôle, puis incite les victimes à visiter ce site web. Il peut le faire en fournissant à l'utilisateur un lien vers le site Web, par le biais d'un courriel ou d'un message sur les médias sociaux.
Il est important de noter que certains exploits CSRF simples utilisent la méthode GET et peuvent être entièrement autonomes avec une seule URL sur le site web vulnérable. Dans cette situation, l'attaquant n'a pas besoin d'utiliser un site externe et peut envoyer directement aux victimes une URL malveillante sur le domaine vulnérable.
Par exemple, disons qu’un individu X a un compte bancaire en ligne sur samplebank.com. Il se rend régulièrement sur ce site pour effectuer des transactions avec son amie, l’individu Y. L’individu X ne sait pas que samplebank.com est vulnérable aux attaques CSRF. Pendant ce temps, un attaquant vise à transférer 5 000 $ du compte de Bob en exploitant cette vulnérabilité. Pour réussir à lancer cette attaque :
- L'attaquant doit construire une URL d'exploitation.
- L'attaquant doit également inciter Bob à cliquer sur l'URL d'exploitation.
- L’individu X doit avoir une session active avec samplebank.com.
Disons que l'application de banque en ligne utilise la méthode GET pour soumettre une demande de transfert. Ainsi, la demande de l’individu X pour transférer 500 $ à l’individu Y (avec le numéro de compte 213367) pourrait ressembler à ceci :
Conformément à la première exigence pour lancer avec succès une attaque CSRF, un attaquant doit créer une URL malveillante pour transférer 5 000 $ sur le compte 425654 :
En utilisant diverses méthodes d'ingénierie sociale, un attaquant peut inciter l’individu X à charger l'URL malveillante. Cela peut se faire de différentes manières. Par exemple, en incluant des éléments d'image HTML malveillants dans des formulaires, en plaçant une URL malveillante sur des pages auxquelles les utilisateurs accèdent souvent lorsqu'ils sont connectés à l'application, ou en envoyant une URL malveillante par courrier électronique.
L'exemple suivant est un exemple d'URL déguisée :
Considérons un scénario dans lequel une balise d'image est incluse dans un courrier électronique rédigé par un attaquant et adressé à l’individu X. À sa réception, l'application de navigation de Bob ouvre automatiquement cette URL, sans intervention humaine. Par conséquent, sans la permission de l’individu X, une requête malveillante est envoyée à l'application de banque en ligne. Si l’individu X a une session active avec samplebank.com, l'application traitera cette demande comme une demande de transfert de montant autorisé provenant de l’individu X. Elle transfère alors le montant sur le compte spécifié par l'attaquant.
Il y a quelques limitations. Ainsi, pour qu'une attaque CSRF soit possible, trois conditions essentielles doivent être réunies :
- Une action pertinente.
Il existe une action dans l'application que l'attaquant a une raison d'induire. Il peut s'agir d'une action privilégiée (telle que la modification des autorisations pour d'autres utilisateurs) ou d'une action sur des données propres à l'utilisateur (telle que la modification du mot de passe de l'utilisateur).
- Une gestion de session basée sur les cookies.
La réalisation de l'action implique l'émission d'une ou plusieurs requêtes HTTP, et l'application s'appuie uniquement sur les cookies de session pour identifier l'utilisateur qui a effectué les requêtes. Il n'y a aucun autre mécanisme en place pour suivre les sessions ou valider les demandes des utilisateurs.
- Pas de paramètres de requête imprévisibles.
Les requêtes qui exécutent l'action ne contiennent aucun paramètre dont l'attaquant ne peut déterminer ou deviner la valeur. Par exemple, lorsqu'on demande à un utilisateur de changer son mot de passe, la fonction n'est pas vulnérable si un attaquant doit connaître la valeur du mot de passe existant.
Comment se prémunir et éviter les attaques CSRF ?
Il existe un certain nombre de méthodes efficaces pour prévenir et atténuer les attaques CSRF. Du point de vue de l'utilisateur, la prévention consiste à protéger les identifiants de connexion et à refuser aux acteurs non autorisés l'accès aux applications.
Les meilleures pratiques sont les suivantes:
- Se déconnecter des applications Web lorsqu'elles ne sont pas utilisées
- Sécuriser les noms d'utilisateur et les mots de passe
- Ne pas permettre aux navigateurs de se souvenir des mots de passe
- Éviter de naviguer simultanément lorsque l'on est connecté à une application.
Pour les applications web, il existe de multiples solutions pour bloquer le trafic malveillant et prévenir les attaques. L'une des méthodes d'atténuation les plus courantes consiste à générer des jetons aléatoires uniques pour chaque demande de session ou ID. Ceux-ci sont ensuite contrôlés et vérifiés par le serveur. Les demandes de session comportant des jetons en double ou des valeurs manquantes sont bloquées. Une demande qui ne correspond pas à son jeton d'identification de session est empêchée d'atteindre une application.
La double soumission des cookies est une autre méthode bien connue pour bloquer CSRF. Comme pour l'utilisation de jetons uniques, des jetons aléatoires sont attribués à la fois à un cookie et à un paramètre de requête. Le serveur vérifie ensuite que les jetons correspondent avant d'accorder l'accès à l'application.
Bien qu'efficaces, les jetons peuvent être exposés à plusieurs endroits, notamment dans l'historique du navigateur, les fichiers journaux HTTP, les appareils réseau enregistrant la première ligne d'une requête HTTP et les en-têtes de référence, si le site protégé renvoie à une URL externe. Ces points faibles potentiels font des jetons une solution qui n'est pas totalement infaillible.
.png)
.png)
