Que sont les attaques CSRF et comment les prévenir?
La falsification de requêtes intersites (CSRF) est l'un des moyens les plus anciens 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 à faire une requête Web non autorisée et malveillante en son nom.
Des pratiques de sécurité de site Web faibles ou médiocres et la 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 en tant qu'utilisateur.
Comment les attaques CSRF vous affectent-elles?
Un CSRF est une attaque utilisée pour implémenter des requêtes non autorisées lors d'actions Web nécessitant 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 profiter 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 un logiciel malveillant.
Une fois que la victime effectue 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 amener les utilisateurs autorisés à perdre 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 toute 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 conduit les utilisateurs à perdre l'accès 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 faut des actions non intentionnelles 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.
Regardons la signification de ces termes:
- GET: une demande de collecte d'un résultat à partir de la base de données; par exemple, la recherche Google.
- POST: généralement pour soumettre des demandes via des formulaires Web. Une demande POST est courante lors de l'inscription ou de la connexion d'un utilisateur, également appelée authentification.
- SUPPRIMER: pour supprimer une ressource de la base de données. Vous faites cela 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 le changement de 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'ils ont créée via CSRF.
Un utilisateur sans méfiance pense alors que la redirection provient du fournisseur de services et clique sur le lien sur la page Web de l'attaquant. Une fois qu'ils ont fait cela, les pirates soumettent un formulaire au chargement de la page à leur insu.
Exemple d'attaque CSRF de requête GET
Imaginez essayer d'effectuer un paiement en ligne via une plate-forme de commerce électronique non sécurisée. Les propriétaires de la plateforme utilisent la requête 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 voler votre transaction facilement 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 changer 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 demande GET modifiée, vous finissez par effectuer un transfert non intentionnel vers le compte de l'attaquant.
La transaction via des requêtes GET est une mauvaise pratique et rend les activités vulnérables aux attaques.
Exemple d'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 ce soit vrai, malheureusement, une requête POST est également sensible aux attaques CSRF.
Pour détourner avec succès une requête POST, tout ce dont un attaquant a besoin est votre identifiant de session actuel, certains formulaires invisibles répliqués et parfois un peu d'ingénierie sociale.
Par exemple, un formulaire de demande POST peut ressembler à ceci:
<form action="Company ABC's account" method="POST">
<input type="text" name="name" placeholder="name"><br>
<input type="number" name="amount"><br>
<input type="submit" name="submit">
</form>Cependant, un attaquant peut échanger vos informations d'identification en créant une nouvelle page et en modifiant le formulaire ci-dessus en ceci:
<body onload="document.getElementById('payment-form').submit();">
<form action="Attacker's account" id="payment-form" method="POST">
<input type="text" hidden name="name" placeholder="name"><br>
<input type="number" hidden value=30000 name="amount"><br>
<input type="submit" hidden name="submit">
</form>
</body>Dans le formulaire manipulé, l'attaquant définit la valeur du champ de montant sur «30000», échange le numéro de compte du destinataire contre le leur, soumet le formulaire au chargement de la page et masque également les champs du formulaire à l'utilisateur.
Une fois qu'ils détournent cette session en cours, votre page de transaction lance une redirection vers la page de l'attaquant, ce qui vous invite à cliquer sur un lien qu'il sait que vous êtes le plus susceptible de visiter.
Cliquer dessus charge 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 tels que «envoyer» pour que la transaction ait lieu, car JavaScript le fait automatiquement lors du chargement de la page Web suivante.
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 nom d'utilisateur ou un changement de mot de passe, un exemple de requête PUT. Un attaquant réplique votre formulaire de demande et remplace votre adresse e-mail par la leur.
Ensuite, ils volent votre session et vous redirigent vers une page ou vous envoient un e-mail qui vous invite à 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 prévenir les attaques CSRF en tant que développeur
L'une des meilleures méthodes pour empêcher un CSRF est d'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.
De nombreux frameworks backend modernes offrent une sécurité contre CSRF. Donc, si vous souhaitez éviter vous-même les aspects techniques du renforcement contre CSRF, vous pouvez vous y attaquer facilement en utilisant des frameworks côté serveur qui sont livrés 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 évitez que votre session ne soit devinée 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 prévenir les attaques CSRF en tant qu'utilisateur
En tant qu'utilisateur d'un service Web impliquant une authentification, vous avez 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 des activités impliquant un transfert de fonds.
En plus de cela, utilisez des navigateurs Web sécurisés qui protègent les utilisateurs contre l'exposition de session, ainsi que des moteurs de recherche sécurisés qui protègent contre les fuites de données de recherche.
En tant qu'utilisateur, vous pouvez également compter sur des 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 pirater 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 régulièrement tester 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 enfreindre d'autres paramètres de sécurité en essayant de bloquer un CSRF.