Sommaire
Les attaques CSRF sont toujours d'actualité
Qu'est-ce qu'un CSRF ?
Le Cross-Site Request Forgery (CSRF) est une vulnérabilité de sécurité web qui
permet à un attaquant de forcer des utilisateurs ciblés à effectuer des actions qu'ils ne souhaitent pas, souvent sans qu'ils s'en aperçoivent.
Cette attaque est en général menée en envoyant un lien à une victime.
L'impact de cette vulnérabilité dépend largement de l'action réalisée.
Si l'attaquant parvient à faire changer l'adresse e-mail ou le mot de passe de l'utilisateur ciblé, cela peut entraîner une prise de contrôle complète du compte.
Nous avons également vu des cas où un attaquant peut forcer un utilisateur
ciblé à publier un message sur un réseau social, ce qui peut nuire à la réputation de la victime.
L'attaque
Cet exemple est tiré d'une exploitation CSRF que nous avons trouvée sur un site web en production cette année (2024).
Cette exploitation est possible car toutes les conditions suivantes sont réunies :
- la session est stockée dans un cookie (et non dans un en-tête HTTP, par exemple) ;
- l'attribut "SameSite" de ce cookie est "None" (ce ne serait pas possible s'il était "Lax" ou "Strict") ;
- cette action peut être réalisée sans saisir le mot de passe du compte.
Pour exploiter ce CSRF, l'attaquant peut héberger la page HTML suivante sur son site web, à une URL qui semble innocente comme https://evil.com/extremely-cool-article.html :
1<!DOCTYPE html>
2<html>
3 <head>
4 <title>CSRF</title>
5 </head>
6
7 <body>
8 <h1>Salut, vous êtes victime d'une attaque CSRF :D</h1>
9 <script>
10 fetch("https://vulnerable.com/api/user/update_profile", {
11 method: "POST",
12 credentials: "include",
13 headers: {"Content-Type": "application/x-www-form-urlencoded"},
14 body: "[email protected]"
15 });
16 </script>
17 </body>
18</html>
Lorsque l'attaquant envoie ce lien à une personne ayant une session active sur vulnerable.com, l'adresse e-mail de leur compte sera modifiée en [email protected] sans qu'ils s'en aperçoivent.
L'attaquant peut alors utiliser la fonctionnalité "mot de passe oublié" sur vulnerable.com pour réinitialiser le mot de passe de la victime, car le lien de réinitialisation sera envoyé à l'adresse e-mail de l'attaquant, lui donnant ainsi un accès complet au compte.
La défense
Les jetons CSRF
Un moyen efficace de se défendre contre les exploitations CSRF est d'inclure un jeton CSRF dans les requêtes pertinentes.
Un jeton CSRF doit être imprévisible, avec une grande entropie, et lié à la session de l'utilisateur. Chaque requête contenant un jeton CSRF doit être validée.
Une méthode courante pour envoyer des jetons CSRF consiste à les inclure comme un champ caché dans un formulaire HTML :
1<input type="hidden" name="csrf_token" value="c0IwjZNkjkR4XbisJF39dI8kyWqznWX9wX4WF8o9zixk2k" />
Cela inclura le paramètre csrf_token dans la requête HTTP, et le serveur doit valider que le jeton est bien celui lié à la session de l'utilisateur avant d'exécuter l'action de la requête.
Il va sans dire que le serveur doit rejeter toute requête ne contenant pas le paramètre csrf_token.
De nombreux frameworks applicatifs intègrent une prise en charge des jetons CSRF, comme Django et Ruby on Rails.
L'attribut SameSite des cookies
L'attribut SameSite est un mécanisme de sécurité des navigateurs qui détermine si un cookie doit ou non être inclus dans les requêtes provenant d'autres sites web. Il est défini dans la réponse HTTP :
1Set-Cookie: session=f481ed500632212c96d1a9816ebb8dbc; SameSite=Strict
Il dispose de 3 modes :
- Strict : le cookie ne peut être envoyé que si le site associé au cookie est celui affiché dans la barre d'adresse du navigateur. Cela signifie que si un utilisateur suit un lien vers votre site depuis un autre, le cookie ne sera pas envoyé.
- Lax : permet au navigateur d'envoyer le cookie lorsqu'un utilisateur clique sur un lien, mais pas lors de l'utilisation de JavaScript ou d'un formulaire HTML.
- None : le cookie est envoyé dans tous les contextes.
De nos jours, tous les navigateurs majeurs utilisent le mode "Lax" par défaut s'il n'est pas spécifié (auparavant, c'était "None"), ce qui a contribué à réduire le nombre d'exploitations CSRF dans la nature.
Un détail important à garder à l'esprit est que la définition de "SameSite" est différente
de la définition de même "origine", utilisée dans la Same Origin Policy.
En effet, les sous-domaines sont considérés comme faisant partie du même site, consultez la liste des suffixes publics pour plus d'informations.
Par exemple, si un utilisateur sur quintessence.sh effectue une requête vers static.quintessence.sh, c'est une requête du même site. Cela s'applique également aux sous-domaines, donc une requête de static.quintessence.sh vers dev.quintessence.sh est également du même site.
Cela signifie que si un utilisateur est capable de téléverser un fichier HTML sur files.vulnerable.com, il peut contourner l'attribut SameSite et effectuer des actions sur app.vulnerable.com en envoyant un lien vers leur fichier téléversé. C'est pourquoi nous recommandons toujours d'utiliser des jetons CSRF en plus de définir l'attribut SameSite.
Conclusion
Les attaques CSRF sont l'une des vulnérabilités web les plus simples, mais aussi l'une des plus faciles à contrer.
Il est possible que votre application soit déjà sécurisée contre les CSRF sans même que vous le sachiez. Cela dit, il est encore
possible de trouver des exploitations CSRF sur des sites en production aujourd'hui, ce qui peut avoir un impact significatif sur les utilisateurs.
Nos services
Nous sommes une équipe de consultants en cybersécurité dédiés à identifier les faiblesses et à aider les organisations à renforcer leur posture de sécurité.
Nous garantissons la confidentialité grâce à des communications chiffrées via PGP et acceptons toutes les clauses de confidentialité que vous pourriez proposer.
Nous sommes spécialisés dans les tests d'intrusion, les audits de code et la surveillance pour assurer la sécurité de vos services et infrastructures.
Vous pouvez nous contacter à [email protected] si vous avez des questions ou avez besoin d'aide pour vos besoins en cybersécurité.