Sécurisation des cookies : passez au niveau supérieur avec l’attribut SameSite

Après avoir lu notre précédent billet dédié à la sécurisation des cookies, 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 l’utilisation du cookie côté client (eg: Javascript).
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).

Sécurisation des cookies

SameSite : un nouvel attribut pour définir quand envoyer (ou non) un cookie

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.
Same-Site propose 2 politiques différentes, qui seront définies par les valeurs suivantes (sensibles à la casse) : Strict (par défaut) 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.

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

Same-Site en mode “Lax”

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 dareboost.com, en cliquant ce lien, 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, vous pouvez utiliser le mode Lax pour l’éviter.

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

Attention ! Strict est le mode par défaut. Toute erreur de frappe pour la valeur Lax aura donc pour résultat l’application du mode Strict.

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://myapp.com/updateUserEmail?newEmail=attacker@example.com

on peut supposer qu’elle déclenche la modification de l’adresse e-mail de l’utilisateur.
Un attaquant qui parviendrait à faire exécuter une telle requête par un utilisateur connecté à son insu, se trouverait donc en position de prendre le contrôle du compte, tout simplement en envoyant une autre adresse email en paramètre.

Le social engineering est fréquemment utilisé 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 (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 token fourni au navigateur web par le serveur, qui est inclus dans la requête émise par le navigateur. Toute requête ne contenant par un token valide étant ensuite automatiquement rejetée par le serveur web).

L’utilisation d’un cookie avec Same-Site (en mode strict) 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 !)

Support de Same-Site

D’autres facteurs limitent encore l’efficacité de la protection offerte par Same-Site contre les attaques CSRF, au premier rang desquels figure le support partiel de cette instruction par les navigateurs web.

Support SameSite par les navigateurs

Ainsi, même si Firefox a clairement montré des signes d’intérêt pour cette nouvelle fonctionnalité, Chrome et Opera sont aujourd’hui les deux seuls navigateurs à la supporter.

Au moins, les navigateurs ne supportant pas pour le moment Same-Site, ignoreront purement et simplement l’instruction : pas de crainte à avoir, donc, concernant sa compatibilité.

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.
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 spécification :

“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.”

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*