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 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 utilisateur.
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 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 le contrôle de l'intégralité de la session et agit au nom des utilisateurs.
Le CSRF a été utilisé pour détourner des transactions de fonds sur le Web ainsi que pour modifier des noms d'utilisateur et des mots de passe, ce qui entraîne la perte de l'accès des utilisateurs au service concerné.
Les principales cibles des attaques CSRF sont les actions Web impliquant l'authentification d'un utilisateur. Pour réussir, il faut des 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.
Regardons la signification de ces termes :
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 peu méfiant 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 envoient un formulaire lors du chargement de la page à leur insu.
Imaginez essayer d'effectuer un paiement en ligne via une plateforme 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=[compte de la société ABC] 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, 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=[compte de l'attaquant] 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.
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, c'est de votre identifiant de session actuel, de certains formulaires invisibles répliqués et parfois d'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 :
Dans le formulaire manipulé, l'attaquant définit la valeur du champ du montant sur "30000", remplace le numéro de compte du destinataire par le sien, soumet le formulaire au chargement de la page et masque également les champs du formulaire à l'utilisateur.
Une fois qu'ils ont piraté 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'ils savent 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 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 HTML intégré 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 requête 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.
L'une des meilleures méthodes pour empêcher un CSRF consiste à utiliser des jetons changeant 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 voulez éviter les détails techniques de renforcement contre CSRF vous-même, vous pouvez y faire face 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 requêtes 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 l'exécution de transactions sur votre application Web réduit également les risques de 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.
En tant qu'utilisateur d'un service Web qui implique une authentification, vous avez un rôle à jouer pour empêcher les attaquants de voler vos informations d'identification et vos sessions via CSRF également.
Assurez-vous d'utiliser des services Web de confiance lors d'activités impliquant un transfert de fonds.
De plus, utilisez des navigateurs Web sécurisés qui protègent les utilisateurs contre l'exposition des sessions, 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.
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. Assurez-vous donc que vous n'avez pas enfreint d'autres paramètres de sécurité en essayant de bloquer un CSRF.