Qu'est-ce que la falsification des requêtes intersites ?

Qu'est-ce que le Cross-Site Request Forgery (CSRF) ?

Une attaque par falsification de requête intersite est un type de cyberattaque * confuse qui incite un utilisateur à utiliser accidentellement ses informations d'identification pour invoquer une activité de changement d'état, telle que le transfert de fonds depuis son compte, la modification de son adresse e-mail et de son mot de passe, ou certaines autre action indésirable.

Si l'impact potentiel sur un utilisateur ordinaire est important, une attaque CSRF réussie contre un compte administratif peut compromettre un serveur entier, ce qui peut entraîner la prise de contrôle complète d'une application web, d'une API ou d'un autre service.

Comment fonctionne le Cross-Site Request Forgery ?

Cette attaque vise à cibler les demandes de changement d'état, c'est-à-dire le type de demande qui entraîne le passage d'une valeur à une autre. Par exemple, une requête ciblée peut effectuer un achat ou modifier une valeur dans un compte. Il est intéressant de noter qu'il s'agit d'une "attaque aveugle", qui ne renvoie pas de données à l'attaquant, ce qui en fait un mauvais choix pour vol de données.

Voici un exemple des 4 étapes d'une attaque de type "cross-site request forgery" :

1. Un pirate crée une fausse demande qui, lorsqu'elle est exécutée, transfère 10 000 dollars d'une banque particulière sur le compte du pirate.
2. L'attaquant incorpore la fausse demande dans un lien hypertexte et l'envoie dans des courriers électroniques de masse, ainsi que dans des sites Web.
3. Une victime clique sur un courriel ou un lien de site Web placé par l'attaquant, ce qui l'amène à demander à la banque de transférer 10 000 $.
4. Le serveur de la banque reçoit la demande, et comme la victime est correctement autorisée, il la traite comme légitime et transfère les fonds.

Les attaques CSRF varient en termes de méthodologie, mais présentent généralement les caractéristiques suivantes :

1. Ils exploitent des sites web qui reposent sur l'identité d'un utilisateur.
2. Ils incitent le navigateur de l'utilisateur à envoyer des requêtes HTTP au site ciblé.
3. Elles impliquent l'utilisation de requêtes HTTP qui ont des effets secondaires et ne disposent pas des protections CSRF appropriées.

Les différents verbes HTTP présentent une vulnérabilité variable aux attaques CSRF, ce qui entraîne des stratégies de protection variables. Ceci est dû à la façon dont les navigateurs web traitent les verbes différemment.

Les requêtes HTTP GET contiennent des paramètres intégrés, tels que ceux contenus dans les balises d'image, qui peuvent être manipulés et exploités. En général, les requêtes GET ne modifient pas l'état, ce qui les rend inefficaces comme cibles de CSRF pour une application web ou une autre ressource correctement implémentée.

HTTP POST est utilisé pour changer d'état, ce qui entraîne un besoin accru de protection. À cette fin, les navigateurs web mettent en œuvre des mesures de sécurité appelées "same origin policy" (SOP) et "cross origin resource sharing" (CORS) qui contient la politique de sécurité de l'origine croisée. La politique SOP n'autorise que les demandes provenant de la même origine et la politique CORS n'autorise que certains types de demandes provenant d'une origine différente. La combinaison de ces implémentations permet de prévenir les attaques CSRF (entre autres) en limitant la capacité d'une requête ou d'une page web à interagir avec une origine différente.

D'autres verbes HTTP, tels que PUT et DELETE, ne peuvent être exécutés qu'en utilisant SOP et CORS, ce qui atténue de nombreuses attaques intersites.

Bien que cela soit rare, certains sites Web désactivent explicitement ces mesures de sécurité. Il est également possible de les désactiver dans un navigateur Web.

Comment atténuer les risques de contrefaçon de requêtes intersites ?

La méthode la plus courante pour atténuer les attaques CSRF consiste à utiliser des jetons Anti-CSRF selon l'une des deux méthodes suivantes. Bien que les implémentations des jetons soient légèrement différentes, le principe sous-jacent reste le même ; en créant puis en comparant une chaîne de jetons générée de manière aléatoire, un attaquant a moins de chances de pouvoir réaliser une attaque sans une supposition exceptionnellement improbable.

Modèle de jeton de synchronisation :

Lorsqu'un utilisateur visite une page Web, telle que celle de la banque qui permet le transfert de fonds, le site Web de la banque intègre un jeton aléatoire dans le formulaire. Lorsque l'utilisateur soumet le formulaire, le jeton aléatoire est renvoyé et la banque est en mesure de vérifier si les deux jetons correspondent. Si les jetons correspondent, le transfert a lieu. L'attaquant n'a aucun moyen d'accéder à la valeur du jeton aléatoire créé dans la page Web, et s'il demande la page, la même politique d'origine l'empêcherait de lire la réponse.

L'inconvénient de cette méthode d'atténuation est qu'elle augmente la charge de travail du serveur qui doit vérifier la validité des jetons à chaque demande. Cela peut également créer des problèmes si un utilisateur a plusieurs fenêtres de navigateur ou d'autres conditions qui impliquent différents logiciels effectuant la demande. En élargissant le champ d'application du jeton à une session plutôt qu'à une demande, certaines de ces difficultés peuvent être évitées.

Jeton de cookie à l'en-tête :

Une autre méthode consiste à envoyer au navigateur web du visiteur un cookie contenant un jeton aléatoire. Le JavaScript opérant côté client lira la valeur du jeton dans le cookie et la copiera dans un en-tête HTTP qui sera envoyé avec chaque demande. Si une demande authentique est envoyée par l'utilisateur, la valeur de l'en-tête peut être vérifiée par le serveur. Toute autre instance échouera, ce qui atténuera la réussite de l'attaque.

En utilisant des règles personnalisées via un WAF , les utilisateurs peuvent contribuer à prévenir certaines attaques CSRF. Explorez le Web Application Firewall de Cloudflare.

*Confusion du problème de l'adjoint

Un adjoint confus fait référence à un programme informatique qui est trompé et qui abuse de son autorité. Le risque associé à ce type de vulnérabilité est la raison pour laquelle la sécurité basée sur les capacités permet de réduire les risques liés à l'abus. Lors de l'installation d'un logiciel, par exemple, la plupart des ordinateurs actuels demandent à l'utilisateur de se connecter. Cela permet d'éviter que du code ne soit exécuté involontairement lorsque l'utilisateur utilise accidentellement son autorité pour autoriser une installation.

FAQ

Qu'est-ce que la falsification de requêtes intersites (CSRF) ?

Le CSRF est une cyberattaque qui trompe un utilisateur afin qu'il utilise ses identifiants pour effectuer des actions indésirables sur une application web où il est authentifié.

Quel est le problème de l'adjoint confus ?

Le problème de l'adjoint confus (confused deputy) est une vulnérabilité de sécurité dans laquelle un programme disposant de moins de privilèges manipule un programme plus privilégié pour faire usage de son autorité de manière abusive.

Que sont les jetons anti-CSRF ?

Les jetons anti-CSRF sont un moyen de réduire les attaques par falsification de requêtes intersites (CSRF). Ce sont des jetons contenant des valeurs aléatoires ajoutées aux requêtes web pour vérifier leur légitimité. Il est hautement improbable que des attaquants puissent deviner les valeurs aléatoires et falsifier des requêtes valides.

Qu'est-ce que la politique de même origine (SOP) ?

La politique de même origine est un mécanisme de sécurité des navigateurs qui restreint les interactions des pages web à la même origine, ainsi les attaques intersites telles que les attaques CSRF sont empêchées.

Comment les verbes HTTP influencent-ils la vulnérabilité aux CSRF ?

Les différentes méthodes (ou verbe) du protocole HTTP (GET, POST, PUT, DELETE) présentent des vulnérabilités variables face aux attaques CSRF. Les requêtes POST, parce qu'elles sont utilisées pour changer d'état, sont plus souvent ciblées et nécessitent une protection plus forte.