Se protéger des attaques CSRF avec l’instruction SameSite sur les cookies

Qu’est-ce qu’une attaque Cross Site Request Forgery ?

L’attaque CSRF (ou en français falsification de requête intersite) est une attaque qui oblige un utilisateur final à exécuter des actions non désirées et sans qu’il s’en rende compte sur une application web dans laquelle il est actuellement authentifié.
Les attaques CSRF visent spécifiquement les demandes de modification et non le vol de données, car l’attaquant n’a aucun moyen de voir la réponse à la demande falsifiée. Le résultat des actions est ce qui intéresse l’attaquant.

Ce type d’attaque s’appuie sur le fait que lorsqu’un utilisateur est authentifié sur une application, celle-ci lui fournit la plupart du temps un identifiant de session, stocké dans un cookie sur son navigateur.
A chaque fois que l’utilisateur envoie une requête vers le serveur, le navigateur envoie également automatiquement ce cookie de session. Vous trouverez dans l’article lié plus d’informations à propos des attaques CSRF.

Notez bien qu’il suffit que l’utilisateur soit resté connecté (sans avoir une page ou un onglet du site ouvert) pour qu’une attaque CSRF fonctionne.

Avec des attaques utilisant de l’ingénierie sociale (telle que l’envoi d’un lien par email ou par chat), un attaquant peut amener les utilisateurs d’une application web à exécuter les actions de son choix.

• Si la victime est un utilisateur standard, une attaque CSRF réussie peut obliger l’utilisateur à exécuter des modifications, telles que la modification de son adresse électronique, de son IBAN, etc.
• Si la victime possède un compte administrateur, une attaque CSRF peut compromettre l’ensemble de l’application web, en raison des différents droits qu’elle a sur l’application.

Une autre manière de se protéger : l’instruction SameSite

Pour se protéger des attaques CSRF, il existe la classique solution du token anti-CSRF. En deux mots : cela consiste à générer une valeur aléatoire dans les formulaires, de sorte que la requête ne puisse pas être prédite.

Depuis, une nouvelle solution a fait son apparition. Il s’agit de l’instruction « SameSite » qu’une application peut placer sur les cookies qu’elle communique au navigateur du client.

Lorsque cette instruction est placée sur les cookies de sessions, alors ceux-ci ne seront pas envoyés au serveur si la requête ne provient pas du domaine de l’application.

L’application recevant la requête ne sera pas capable de relier la requête à un quelconque utilisateur et par conséquent ne la traitera pas. Cela permet donc en théorie de se protéger totalement de ce type d’attaque.

Prise en charge de cette instruction

Au moment d’écrire cette article (octobre 2018), cette instruction n’est pas encore supportée par l’ensemble des navigateurs. Edge, Firefox et Chrome supportent correctement cette fonctionnalité, alors que celle-ci n’est pas supportée par Safari pour des versions d’iOS inférieures à iOS12.

Vous pouvez suivre ici l’évolution des versions qui supportent l’instruction.

 

L’instruction SameSite en détail

Lorsque l’application va créer le cookie de sessions sur le navigateur du client, celle-ci devra ajouter l’instruction « SameSite=strict » ou « SameSite=lax ».

Exemple :

Set-Cookie: PHPSESSID=6qc74h21i12ucl4i3l5oc5af07; expires=Thu, 11-Oct-2018 15:47:30 GMT; Max-Age=3600; path=/; domain=192.168.240; secure; HttpOnly; SameSite=strict

Le mode « strict » est le plus restrictif : si l’utilisateur requête le site à partir d’un site tiers, alors son cookie de session sera systématiquement ignoré. L’inconvénient est donc qu’un utilisateur ayant cliqué sur un lien l’amenant sur le site sera toujours considéré par l’application comme n’étant pas connecté, et cela même s’il s’y était préalablement authentifié.

Pour éviter ça, il est possible d’utiliser le mode « lax », qui permettra au navigateur d’envoyer les cookies si la requête est un simple GET (exemple : clique sur un lien), mais ne les enverra pas pour une requête POST.

Il est cependant important de noter que si vous utilisez le mode « lax », il sera toujours possible d’effectuer des attaques CSRF sur les paramètres des requêtes GET de votre application, ce qui ne devrait pas avoir de fort impact si l’utilisation de la méthode POST est implémentée normalement.

Par ailleurs, la mise en place de cette instruction n’est pas encore totalement supportée nativement par tous les langages ou toutes les libraires. Par exemple, pour PHP, il ne sera supporté que dans la version 7.3 qui n’est pas encore disponible en version finale.

 

Conclusion

Ce nouvel élément semble donc très intéressant afin de se protéger contre les attaques de type CSRF. Cependant, il ne doit pour le moment pas être utilisé comme seul rempart, mais en complément des protections plus classiques comme les token anti-CSRF.

Auteur : Romain Garcia