SameSite cookie attribute : passez au niveau supérieur de sécurité pour vos cookies

Ici, on vous parle de web performances et de cookies. Pour bien optimiser votre site Web d’un point de vue technique avec les cookies, nous vous présentons dans cet article l’attribut “samesite cookie attribute”. A quoi sert-il ? Comment l’utiliser ? On passe le niveau au-dessus !

SameSite cookie attribute : définir quand envoyer (ou non) un cookie

Vous utilisez peut-être déjà les instructions Secure et HttpOnly ? Pour rappel, la première permet d’empêcher l’envoi d’un cookie sur une page non sécurisée (http simple) alors que la seconde empêche d’accéder aux cookies côté client (eg: via Javascript) : seul les réponses HTTP peuvent définir des cookies.

Passons maintenant à l’étape supérieure de la sécurisation de vos cookies avec une nouvelle instruction : SameSite, qui permet de mitiger les risques liés aux attaques de type CSRF (Cross-Site Request Forgery) et XSSI (Cross-Site Script Inclusion).

Le principe de base de SameSite est similaire à celui des flags HttpOnly et Secure : il permet de contrôler le comportement des cookies, en définissant quand ces derniers peuvent être envoyés et quand ils ne le doivent pas.

SameSite propose 3 politiques différentes, qui seront définies par les valeurs suivantes (sensibles à la casse) : None, Strict et Lax.

Same-Site en mode “Strict”

Le cookie concerné par cette instruction ne sera envoyé que si la requête provient du même site web. Il ne sera donc pas envoyé lors d’une première visite sur une page du site, mais uniquement lors des actions qui suivent.

Set-Cookie: SID=31d4d96e407aad42; SameSite=Strict

Same-Site en mode “Lax” (par défaut)

La variante Lax ajoute une exception pour l’envoi du cookie dans le cas où la requête ne provient pas du site d’origine : ce dernier sera aussi communiqué pour les requêtes dites “safe” (essentiellement celles de type GET) dans le cadre d’une navigation de premier niveau (impliquant un changement d’URL dans la barre d’adresse du navigateur).

En effet, le mode Strict empêcherait l’envoi d’un cookie de session dans le cas d’un accès au site via un lien externe (depuis un e-mail, un moteur de recherche, etc.), un utilisateur suivant un tel lien ne pourrait donc pas être connecté à son compte à son arrivée sur le site.

Par exemple, si nous utilisions l’instruction SameSite en mode Strict sur https://contentsquare.com/ en accédant au service depuis votre moteur de recherche favoris, vous ne seriez pas détecté comme connecté, même si vous l’êtes déjà dans un autre onglet de votre navigateur.

Ce type de comportement pouvant induire de la confusion chez les utilisateurs finaux, ce mode a été préféré à “Strict” pour la sécurisation par défaut des navigateurs

Set-Cookie: SID=31d4d96e407aad42; SameSite=Lax

Same-Site en mode “None” (mais “Secure”)

Les cookies seront envoyés quel que soit le contexte de l’appel. C’était le mode par défaut lors de la création de l’attribut SameSite, mais ça ne l’est plus aujourd’hui. Un cookie SameSite None qui n’utiliserait pas également le mot-clé “Secure” sera refusé.

Set-Cookie: SID=31d4d96e407aad42; SameSite=None; Secure

Cross-Site Request Forgery : le problème de départ

Tel que le définit l’OWASP, une attaque CSRF (Cross-Site Request Forgery) force un utilisateur à exécuter des actions à son insu au sein d’une application web où il est authentifié.

Illustration, avec une URL construite comme telle :

https://mydomain.com/updateUserEmail?newEmail=attacker@example.comqui déclenche la modification de l’adresse e-mail de l’utilisateur.

Un attaquant qui parviendrait à faire exécuter une telle requête à son insu par un utilisateur connecté à mydomain.com, se trouverait donc en position de prendre le contrôle du compte, tout simplement en envoyant une autre adresse email en paramètre.

De nombreuses techniques sont fréquemment utilisées pour piéger les utilisateurs et les amener à déclencher des requêtes de ce type, par exemple via une image embarquant cette URL dans un attribut SRC et envoyée par mail (d’ailleurs la plupart des clients email bloquent désormais par défaut les images afin de limiter les risques d’attaques CSRF).

Jusque-là, pour prévenir ce type d’attaques, il convenait de vérifier l’en-tête HTTP Referer et/ou d’utiliser des tokens CSRF (un jeton unique fourni au navigateur web par le serveur, qui est inclus dans la requête émise par le navigateur et n’accepte qu’une utilisation unique en retour. Toute requête ne contenant par un token valide étant ensuite automatiquement rejetée par le serveur web).

L’utilisation d’un cookie avec SameSite préviendra les risques d’attaques CSRF, à l’exception d’un cas – mentionné dans les spécifications : s’il s’agit d’une attaque combinée CSRF et XSS (n’oubliez pas d’utiliser CSP !)

SameSite cookie attribute : une protection puissante, mais pas totale

En conclusion, Same-Site s’avère être une instruction dont l’utilisation est à envisager très sérieusement, notamment si votre site web permet à vos utilisateurs de réaliser des actions sensibles, ou s’il génère un trafic important. Même si la protection “SameSite: Lax”, déployée par défaut par les navigateurs, est intéressante, il n’en reste pas moins que “SameSite: Strict” est bien plus adapté dès lors que l’on cherche à sécuriser des actions utilisateurs.

A noter également que l’attribut SameSite est une protection contre les attaques de type XSSI (Cross-site script inclusion) et les attaques temporelles.

Gardez toutefois à l’esprit que cette nouvelle instruction ne peut constituer qu’une couche de sécurité supplémentaire et ne doit en aucun cas être votre unique défense contre ce type d’attaques, comme nous le rappelle d’ailleurs la RFC 6265 bis :

“Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that « safe » HTTP methods are idempotent, etc) to mitigate the risk more fully.”