Que sont les attaques CSRF et comment les empêcher ?

Le Cross-Site Request Forgery (CSRF) est l'un des plus anciens moyens d'exploiter les vulnérabilités d'un site Web. Il cible les commutateurs Web côté serveur qui nécessitent généralement des authentifications telles que la connexion. Lors d'une attaque CSRF, un attaquant vise à forcer sa victime à effectuer une demande Web malveillante non autorisée en son nom.

Des pratiques de sécurité de site Web faibles ou médiocres et une négligence sur le chemin de l'utilisateur sont quelques-unes des causes courantes d'une attaque CSRF réussie.

Voyons ce qu'est une attaque CSRF et les moyens possibles de vous en empêcher en tant que développeur ou utilisateur.

Comment les attaques CSRF vous affectent-elles ?

Un CSRF est une attaque utilisée pour mettre en œuvre des requêtes non autorisées lors d'actions Web qui nécessitent une connexion ou une authentification de l'utilisateur. Les attaques CSRF peuvent tirer parti des identifiants de session, des cookies, ainsi que d'autres vulnérabilités basées sur le serveur pour voler les informations d'identification d'un utilisateur.

Par exemple, l'activation des procédures anti-CSRF empêche les interactions malveillantes entre domaines.

Une fois cette barrière franchie, un attaquant peut rapidement tirer parti de l'ID de session de l'utilisateur via les cookies créés par le navigateur de l'utilisateur et intégrer une balise de script dans le site Web vulnérable.

En manipulant un identifiant, l'attaquant peut également rediriger les visiteurs vers une autre page Web ou exploiter des méthodes d'ingénierie sociale comme le courrier électronique pour envoyer des liens, encourageant la victime à télécharger des logiciels malveillants.

Une fois que la victime a effectué de telles actions, elle envoie une requête HTTP à la page de service de l'utilisateur et autorise l'action de requête en faveur de l'attaquant. Cela peut être dévastateur pour un utilisateur sans méfiance.

Une attaque CSRF réussie peut faire perdre aux utilisateurs autorisés leurs identifiants d'accès au profit d'un attaquant, en particulier lors d'actions basées sur le serveur telles que les demandes de changement de mot de passe ou de nom d'utilisateur. Dans les pires scénarios, l'attaquant prend en charge l'intégralité de la session et agit au nom des utilisateurs.

CSRF a été utilisé pour détourner des transactions de fonds sur le Web ainsi que pour modifier les noms d'utilisateur et les mots de passe, ce qui entraîne la perte d'accès des utilisateurs au service concerné.

Comment les attaquants détournent vos sessions avec CSRF : exemples

Les principales cibles des attaques CSRF sont les actions Web impliquant l'authentification d'un utilisateur. Pour réussir, il a besoin d'actions involontaires de la part de la victime.

Lors d'une attaque CSRF, les actions GET, DELETE et PUT, ainsi que les requêtes POST vulnérables sont les principales cibles d'un attaquant.

Voyons le sens de ces termes :

• GET : Une requête pour collecter un résultat de la base de données ; par exemple, la recherche Google.
• POST : généralement pour soumettre des demandes via des formulaires Web. Une requête POST est courante lors de l'enregistrement ou de la connexion d'un utilisateur, également appelée authentification.
• SUPPRIMER : Pour supprimer une ressource de la base de données. Vous le faites chaque fois que vous supprimez votre compte d'un service Web particulier.
• PUT : une demande PUT modifie ou met à jour une ressource existante. Un exemple est de changer votre nom Facebook .

En pratique, les attaquants utilisent le détournement de session pour sauvegarder une attaque CSRF. Lors de l'utilisation de cette combinaison, l'attaquant peut utiliser un détournement pour modifier l'adresse IP de la victime.

Le changement d'adresse IP connecte ensuite la victime à un nouveau site Web où l'attaquant a inséré un lien trompeur qui soumet un formulaire répliqué ou une demande de serveur modifiée qu'il a créée via CSRF.

Un utilisateur sans méfiance pense alors que la redirection vient du fournisseur de services et clique sur le lien sur la page Web de l'attaquant. Une fois cela fait, les pirates soumettent un formulaire au chargement de la page à leur insu.

Exemple d'attaque CSRF de requête GET

Imaginez que vous essayez d'effectuer un paiement en ligne via une plateforme de commerce électronique non sécurisée. Les propriétaires de la plateforme utilisent la demande GET pour traiter votre transaction. Cette requête GET pourrait ressembler à ceci :

https://websiteurl/pay?amount=$10&company=[company ABC's account]

Un pirate de l'air peut facilement voler votre transaction en modifiant les paramètres de la requête GET. Pour ce faire, il leur suffit d'échanger votre nom contre le leur et, pire encore, de modifier le montant que vous avez l'intention de payer. Ils modifient ensuite la requête d'origine en quelque chose comme ceci :

https://websiteurl/pay?amount=$20000&company=[attacker's account]

Une fois que vous avez cliqué sur un lien vers cette requête GET modifiée, vous finissez par effectuer un transfert involontaire vers le compte de l'attaquant.

Effectuer des transactions via des requêtes GET est une mauvaise pratique et rend les activités vulnérables aux attaques.

Exemple d'une attaque CSRF de requête POST

Cependant, de nombreux développeurs pensent que l'utilisation de la requête POST est plus sûre pour effectuer des transactions Web. Bien que cela soit vrai, malheureusement, une requête POST est également sensible aux attaques CSRF.

Pour réussir à détourner une requête POST, tout ce dont un attaquant a besoin est votre ID de session actuel, des formulaires invisibles répliqués et parfois un peu d'ingénierie sociale.

Par exemple, un formulaire de demande POST pourrait ressembler à ceci :

Cependant, un attaquant peut échanger vos informations d'identification en créant une nouvelle page et en modifiant le formulaire ci-dessus en ceci :

Dans le formulaire manipulé, l'attaquant définit la valeur du champ de montant sur "30000", échange le numéro de compte du destinataire avec le leur, soumet le formulaire au chargement de la page et masque également les champs du formulaire à l'utilisateur.

Une fois qu'ils ont détourné cette session en cours, votre page de transaction initie une redirection vers la page de l'attaquant, qui vous invite à cliquer sur un lien qu'il sait que vous êtes le plus susceptible de visiter.

En cliquant dessus, vous chargez la soumission du formulaire répliqué, qui transfère vos fonds sur le compte de l'attaquant. Cela signifie que vous n'avez pas besoin de cliquer sur des boutons comme « envoyer » pour que la transaction ait lieu, car JavaScript le fait automatiquement lors du chargement de la page Web suivante.

Alternativement, un attaquant peut également rédiger un e-mail intégré au HTML qui vous invite à cliquer sur un lien pour effectuer la même soumission de formulaire de chargement de page.

Une autre action vulnérable à une attaque CSRF est un changement de nom d'utilisateur ou de mot de passe, un exemple de demande PUT. Un attaquant réplique votre formulaire de demande et remplace votre adresse e-mail par la sienne.

Ensuite, ils volent votre session et vous redirigent vers une page ou vous envoient un e-mail vous invitant à cliquer sur un lien attrayant.

Cela soumet ensuite un formulaire manipulé qui envoie le lien de réinitialisation du mot de passe à l'adresse e-mail du pirate au lieu de la vôtre. De cette façon, le pirate modifie votre mot de passe et vous déconnecte de votre compte.

Comment empêcher les attaques CSRF en tant que développeur

L'une des meilleures méthodes pour empêcher un CSRF consiste à utiliser des jetons qui changent fréquemment au lieu de dépendre des cookies de session pour exécuter un changement d'état sur le serveur.

Connexes : Guides gratuits pour comprendre la sécurité numérique et protéger votre vie privée

De nombreux frameworks backend modernes offrent une sécurité contre CSRF. Donc, si vous voulez éviter les détails techniques de vous renforcer contre CSRF, vous pouvez y faire face facilement en utilisant des frameworks côté serveur fournis avec des jetons anti-CSRF intégrés.

Lorsque vous utilisez un jeton anti-CSRF, les demandes basées sur le serveur génèrent des chaînes aléatoires au lieu des cookies de session vulnérables plus statiques. De cette façon, vous protégez votre session d'être deviné par le pirate de l'air.

La mise en œuvre d'un système d'authentification à deux facteurs (2FA) pour exécuter des transactions sur votre application Web réduit également les chances d'un CSRF.

Il est possible d'initier un CSRF via un script intersite (XSS), qui implique l'injection de script dans des champs utilisateur tels que des formulaires de commentaires. Pour éviter cela, il est recommandé d'activer l'échappement automatique HTML dans tous les champs de formulaire utilisateur de votre site Web. Cette action empêche les champs de formulaire d'interpréter les éléments HTML.

Comment empêcher les attaques CSRF en tant qu'utilisateur

En tant qu'utilisateur d'un service Web impliquant une authentification, vous avez également un rôle à jouer pour empêcher les attaquants de voler vos informations d'identification et vos sessions via CSRF.

Assurez-vous d'utiliser des services Web de confiance lors d'activités impliquant un transfert de fonds.

En plus de cela, utilisez  des navigateurs Web sécurisés qui protègent les utilisateurs de l'exposition des sessions, ainsi que des moteurs de recherche sécurisés qui protègent contre les fuites de données de recherche.

Connexe : Les  meilleurs moteurs de recherche privés qui respectent vos données

En tant qu'utilisateur, vous pouvez également dépendre d'authentificateurs tiers tels que Google Authenticator ou ses alternatives pour vérifier votre identité sur le Web.

Bien que vous puissiez vous sentir impuissant à empêcher un attaquant de détourner votre session, vous pouvez toujours aider à empêcher cela en vous assurant que votre navigateur ne stocke pas d'informations telles que les mots de passe et autres informations de connexion.

Renforcez votre sécurité Web

Les développeurs doivent tester régulièrement les applications Web pour détecter les failles de sécurité pendant le développement et le déploiement.

Cependant, il est courant d'introduire d'autres vulnérabilités tout en essayant d'en empêcher d'autres. Veillez donc à ne pas avoir enfreint d'autres paramètres de sécurité en essayant de bloquer un CSRF.