Contenu
Les attaques de type CSRF, ou Cross Sites Request Forgery, font partie du top ten de l’OWASP, c’est-à-dire font partie des attaques les plus courantes et donc contre lesquelles on se protège peu (ou mal) en général.
En français ça signifie quelque chose comme falsification des requêtes (http) inter-sites. Le principe est qu’un utilisateur d’un site A, sur lequel il a les droits d’accès, fasse une requête sur ce site A à son insu lors d’une visite sur un site B.
Ainsi, le site B contiendrait une requête spécialement préparée qui n’attendrait plus qu’à être déclenchée par l’utilisateur.
Quel intérêt ?
Pas toujours évident de le voir à l’œil nu 😉 ! Imaginons que le site A est important mais vulnérable aux attaques CSRF. Le méchant pirate n’y a pas accès (il n’a pas le mot de passe, voire même le site A n’est pas accessible depuis l’extérieur).
Par contre, le site B est facile d’accès pour le pirate, lequel sait (ou espère) qu’il est visité régulièrement par l’utilisateur ayant accès au site A. Le pirate va alors placer sa requête sur le site B, en attendant que l’utilisateur du site A aille visiter le site B… tout en s’étant par ailleurs connecté sur le site A.
L’intérêt est ici : l’utilisateur du site A s’est auparavant authentifié. Il a donc accès aux fonctions qui intéressent le pirate, qui lui n’y a pas accès.
Or en allant sur le site B, l’utilisateur va sans le savoir lancer une requête sur un autre site (le site A) tout en étant déjà authentifié (au niveau de son navigateur).
Résultat : la requête, pourtant lancée à partir du site B, ira sur le site A en conservant (via le navigateur) la session authentifiée du site A, et elle sera donc exécutée !
Conclusion de l’affaire
Sans même avoir physiquement accès au site A, le pirate fera faire à l’utilisateur la requête qui lui, le pirate, souhaite voir s’exécuter sur le site A.
Paradons
Pour empêcher cela, on peut agir soit au niveau du navigateur, soit au niveau de l’application ou du serveur web.
Navigons
En 2018, seuls Chrome et Opera implémentaient un mécanisme de protection qui consiste à ne pas autoriser un cookie (servant à l’authentification) de servir une requête venant d’un autre endroit (same-site cookies).
Les soucis sont qu’on ne peut pas toujours faire confiance au navigateur et que seuls certains d’entre eux appliquent cette parade. La tendance semble toutefois meilleure en 2019, mais il faut avoir un navigateur à jour.
Plus d’infos : https://caniuse.com/#feat=same-site-cookie-attribute.
Niveau serveur
Il faut dans ce cas ne répondre qu’aux requêtes légitimes, c’est-à-dire envoyées par le serveur web lui-même. Pour cela, on ajoute un token (à usage unique) à la requête, qui doit être renvoyé dans la réponse.
Pour être efficace, il faut que ce token ne puisse pas être déterminé par l’attaquant ! Plusieurs frameworks de développement proposent des tokens robustes avec suffisamment d’aléas.
Et si la requête est légitime mais qu’elle ne contient pas de token, alors l’utilisateur doit se ré-authentifier ! Tout simplement.
