Série Partage & Apprentissage : La sécurité pour les développeurs - Cross-Site Request Forgery

Contrairement aux attaques visant directement les opérateurs de sites web ou d'applications, l'objectif de nombreuses attaques par falsification de requête intersite (CSRF) est de voler de l'argent, des biens ou des identifiants directement à un utilisateur. Cela ne signifie pas que les opérateurs de sites doivent ignorer les vulnérabilités de code CSRF, car en fin de compte, le remboursement des fonds volés, dans le cas d'une attaque purement financière, peut incomber au site hébergeur dont le code n'est pas sécurisé. Et si l'utilisateur ciblé perd ses identifiants ou voit son mot de passe modifié à son insu, un criminel pourrait faire des ravages en utilisant cette identité volée, surtout si la victime dispose d'un accès privilégié.

Les attaques CSRF sont assez complexes et reposent sur plusieurs niveaux pour réussir. En d'autres termes, beaucoup de choses doivent jouer en faveur de l'attaquant pour que cela fonctionne. Malgré cela, il s'agit d'un vecteur d'attaque extrêmement populaire car une attaque réussie peut transférer de l'argent directement à un pirate informatique, ou lui permettre de naviguer sur un site en toute impunité. Si tout se déroule comme prévu pour le pirate, l'utilisateur ciblé peut même ne jamais savoir qu'il a été victime d'une attaque.

La bonne nouvelle est que, comme tant de conditions doivent être réunies pour qu'une attaque CSRF fonctionne, il existe de nombreuses excellentes techniques de défense capables de les stopper net.

À cette fin, nous aborderons trois aspects clés des attaques CSRF :

• Comment elles fonctionnent
• Pourquoi elles sont si dangereuses
• Comment mettre en place des défenses pour les contrer efficacement.

Comment fonctionnent les attaques CSRF ?

Parce que les attaques CSRF réussies permettent de voler directement de l'argent, des biens ou des identifiants aux utilisateurs ciblés, elles sont populaires malgré l'important travail nécessaire à leur création. Et comme elles sont souvent tentées sur différentes plateformes, elles ont reçu au fil des ans une variété de noms et de surnoms. Vous pourriez entendre parler des attaques CSRF sous les noms de XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery ou Hostile Linking. Microsoft préfère les appeler attaques « en un clic » dans la plupart de sa documentation. Mais il s'agit toujours d'attaques CSRF, et les techniques pour les contrer sont identiques.

Une attaque CSRF peut se produire si un utilisateur est connecté à un site pour effectuer des transactions ou travailler. L'essentiel est que l'utilisateur soit connecté et authentifié activement auprès d'un site web ou d'une application. L'attaque est généralement lancée depuis un site web secondaire ou un e-mail. Souvent, les attaquants utilisent des techniques d'ingénierie sociale pour inciter les utilisateurs à cliquer sur un lien dans un e-mail qui les dirige vers un site web compromis contenant le script d'attaque.

Le site web compromis contient un script qui ordonne au navigateur actif d'exécuter des commandes, généralement malveillantes, comme changer le mot de passe d'un utilisateur ou transférer de l'argent vers un compte contrôlé par l'attaquant. Tant que l'utilisateur est authentifié, le site pensera que les commandes sont émises par l'utilisateur autorisé. Pourquoi en serait-il autrement ? L'utilisateur s'est déjà authentifié et a fourni tous les mots de passe requis pour accéder au site. Il peut même se trouver dans une zone géographique autorisée, assis correctement à son terminal de bureau. S'il souhaite changer son mot de passe ou transférer des fonds, il n'y a aucune raison de ne pas croire que c'est lui qui fait la demande.

En décomposant les éléments de l'attaque, on comprend pourquoi elle est si difficile à réaliser pour l'attaquant. Pour commencer, l'utilisateur doit être activement authentifié sur le site où l'attaque a lieu. Si un e-mail contenant un script d'attaque arrive après qu'un utilisateur a mis fin à sa session de navigation ou s'est déconnecté, l'attaque échoue.

L'attaquant est également contraint d'effectuer une reconnaissance approfondie du site ciblé afin de savoir quels scripts ce site acceptera. Les attaquants ne peuvent pas voir l'écran de la victime, et tout retour du site web sera envoyé à la victime, et non à l'attaquant. À moins que l'attaquant ne puisse constater les preuves de la réussite de son attaque, comme de l'argent apparaissant soudainement sur son compte, il ne saura même pas immédiatement si elle a réussi.

Dans les paramètres difficiles mais pas impossibles où l'utilisateur est connecté au moment de l'attaque et où l'on connaît les scripts acceptés par le site ciblé, le code pour exécuter une attaque CSRF peut être extrêmement simple, bien qu'il varie en fonction du site lui-même.

Imaginons qu'une banque ou une application financière utilise des requêtes GET pour transférer de l'argent, comme ceci :

GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1

Ce code enverrait une demande de transfert de 100 $ à un utilisateur nommé NancySmith12.

Mais si l'utilisateur ciblé recevait un e-mail, peut-être déguisé pour paraître provenir d'un collègue, un script d'attaque CSRF pourrait être intégré dans l'action de clic :

<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Pouvez-vous lire rapidement ce rapport trimestriel ?<a></a></a>

Si l'utilisateur ciblé tombait dans le piège de l'ingénierie sociale et cliquait sur le lien alors que la session de navigation avec l'application financière était toujours ouverte, son navigateur demanderait à l'application d'envoyer 100 000 $ sur le compte de ShadyLady15.

Le script pourrait même être caché dans une image invisible que l'utilisateur ne verrait pas, mais qui pourrait tout de même déclencher la requête par le navigateur, comme ceci :

<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">

Le résultat est le même. ShadyLady15 reçoit 100 000 $ sans que personne ne détecte l'attaque.

Pourquoi les attaques CSRF sont-elles si dangereuses ?

Les attaques CSRF sont populaires aujourd'hui pour la même raison que les rançongiciels continuent de sévir. Elles réduisent considérablement le nombre d'étapes entre les attaquants et l'argent de la victime. Dans une attaque par rançongiciel, les systèmes sont chiffrés et les utilisateurs doivent payer pour déverrouiller leurs données. Avec une attaque CSRF, le processus est encore plus direct : les victimes envoient simplement de l'argent aux attaquants sans même s'en rendre compte.

Au-delà des attaques directes sur l'argent d'une victime ou les finances d'une entreprise, les attaques CSRF réussies peuvent être utilisées pour compromettre un réseau en exploitant des utilisateurs légitimes. Imaginez qu'un attaquant utilise une faille CSRF pour modifier le mot de passe d'un administrateur. Il pourrait immédiatement utiliser ce mot de passe pour voler des données, créer des brèches dans les défenses réseau ou installer des portes dérobées.

Bien que cela demande beaucoup de travail et, dans une certaine mesure, de la chance, une attaque CSRF réussie peut s'apparenter à un gain au loto pour les pirates, quel que soit leur objectif final. Pour attaquer un réseau, presque tout autre type d'intrusion nécessiterait des mois de reconnaissance discrète pour tenter de passer sous le radar du SIEM et des équipes de cybersécurité. À l'inverse, une seule attaque CSRF permet de sauter plusieurs étapes de la chaîne d'attaque, rapprochant l'attaquant très rapidement de son but ultime.

Comment arrêter les attaques CSRF ?

Contrairement à la plupart des vulnérabilités, le problème avec les attaques CSRF ne réside pas vraiment dans le code lui-même, mais dans un exploit conçu pour forcer un navigateur à effectuer des requêtes non désirées, voire inconnues de l'utilisateur. Cependant, il est possible de les contrer.

L'une des meilleures méthodes consiste à demander aux développeurs d'ajouter un jeton CSRF à l'identité de l'utilisateur lors de la création d'une nouvelle session. Ce jeton doit être une chaîne de caractères unique et aléatoire, invisible pour l'utilisateur. Ensuite, il faut ajouter ce jeton en tant que champ masqué dans les formulaires, lequel sera vérifié par le serveur à chaque soumission. Les attaquants envoyant des requêtes via le navigateur d'un utilisateur ignoreront l'existence de ce champ masqué et ne pourront pas le deviner, ce qui fera échouer toutes leurs tentatives.

Une méthode encore plus simple, qui ne nécessite que peu de programmation, consiste à ajouter un test CAPTCHA pour toute action sensible, comme le changement de mot de passe ou les virements bancaires. Il peut s'agir simplement de demander à l'utilisateur de confirmer qu'il n'est pas un robot, ou dans ce cas, un script CSRF. Les attaquants ne pourront pas automatiser la réponse à ce défi, et les utilisateurs qui se voient soudainement présenter un CAPTCHA sans avoir initié de virement sauront qu'il y a un problème. Alternativement, l'utilisation de mots de passe à usage unique via un jeton tiers, comme un smartphone, peut être envisagée, selon le niveau de sécurité souhaité.

Enfin, bien que ce ne soit pas infaillible, de nombreux navigateurs comme Microsoft Edge ou Google Chrome intègrent désormais des restrictions de politique de même origine pour bloquer les requêtes provenant de sources externes. Forcer les utilisateurs à interagir avec votre site via les versions les plus récentes de ces navigateurs permet d'ajouter une couche de sécurité CSRF sans surcharger les équipes de développement.

Verrouiller la porte contre les attaques CSRF

Avec un tel potentiel de gain, les attaques CSRF ne disparaîtront probablement jamais totalement, mais nous espérons que vous comprenez désormais pourquoi elles persistent et comment les bloquer définitivement sur votre réseau.

Pour aller plus loin, consultez la fiche de prévention CSRF de l'OWASP, un document évolutif qui suit cette vulnérabilité. Si vous souhaitez renforcer vos connaissances en sécurité, apprenez à contrer cette menace et bien d'autres en visitant le blog de Secure Code Warrior.

Prêt à mettre vos nouvelles compétences à l'épreuve ? Essayez la démo gratuite de la plateforme Secure Code Warrior dès aujourd'hui.