Par Ndeye Maty K. - Expert en CyberSécurité
Depuis la mise à jour V.80 de Google Chrome en février 2020, nous avons eu des remontées d’alertes clients ayant des bugs applicatifs liés à l’utilisation de Google Chrome et de la sécurité mise en place (Chrome 80 SameSite cookie attribute enforcement).
Des bugs applicatifs
Nous avons constaté que le déploiement de la mise à jour rencontrait des difficultés avec le cookie de persistance de nos Virtual IPs hébergées sur nos BIG-IP (F5). Nos utilisateurs recevaient l’erreur :
« Chrome 80 SameSite cookie attribute enforcement ».
Google a renforcé les règles liés à la sécurité et à la confidentialité de son navigateur, notamment sur l’utilisation des cookies. Leur objectif : réduire les attaques CSRF (Cross Site Request Forgery) en vérifiant l’attribut « SameSite » dans les cookies conformément à la RFC : rfc6265bis. Cet attribut dicte comment le navigateur doit envoyer les cookies à des domaines tiers (third party domain).
Conséquence : si le serveur générant le cookie ne spécifie pas l’attribut « SameSite » dans le cookie, un comportement par défaut est imposé par le navigateur.
Dans le cas de Chrome, le comportement imposé prend la valeur de « SameSite = Lax ».
La vérification de cet attribut dans les cookies se généralise également auprès des autres navigateurs tels que Firefox et Edge et à terme ces navigateurs imposeront un comportement par défaut au même titre que Chrome :
- Firefox implémente en test ce comportement à partir de la version 69
- Edge implémente en test ce comportement à partir de la version 80
Rappelle des valeurs possibles pour l’attribut « SameSite » ainsi que les cas d’utilisation :
| First-party cookie |
Créé par des sites Web visités par un utilisateur et est utilisé pour enregistrer des données telles que des éléments de panier, des informations d’identification de connexion (par exemple, des cookies d’authentification) et d’autres analyses. |
| Second-party cookie |
Techniquement le même qu’un first-party cookie. La différence réside dans le fait que les données sont partagées avec une tierce partie via un accord de partenariat de données. |
| Third-party cookie |
Installé par un domaine autre que celui que l’utilisateur a visité explicitement et est principalement utilisé pour le suivi (par exemple, les boutons « Like »), le service AD et les live chats. |
SameSite peut avoir 3 valeurs :
| Valeur de l’attribut |
Comportement | Valeur | Spécification d’attribut |
| Lax | Les cookies ne seront envoyés automatiquement que dans un contexte « fisrt-party » et avec des requêtes HTTP Get. Les cookies SameSite seront refusés sur les sous-requêtes intersites (cross-site), telles que les appels pour charger des images ou des IFRAMES, mais seront envoyées lorsqu’un utilisateur navigue vers l’URL à partir d’un site externe, par exemple, en suivant un lien. |
Par défaut | Set-Cookie: key=value; SameSite=Lax |
| Strict | Le navigateur enverra uniquement les cookies pour les demandes de contexte « first-party » (requêtes provenant du site qui définissent le cookie). Si la demande provient d’une URL différente de celle de l’emplacement actuel, aucun des cookies marqués avec l’attribut Strict n’est envoyé. |
Facultatif | Set-Cookie: key=value; SameSite=Strict |
| None | Les cookies sont envoyés aussi bien dans le contexte « first-party » que dans les requêtes « cross-origin » (requêtes croisées). Cependant, la valeur doit être définie explicitement sur None et toutes les requêtes de navigateur doivent suivre le protocole HTTPS et inclure l’attribut Secure qui nécessite une connexion chiffrée. Les cookies qui n’adhèrent pas à cette exigence seront rejetés. Les deux attributs sont requis ensemble. Si seul None est spécifié sans Secure ou si le protocole HTTPS n’est pas utilisé, le cookie tiers est rejeté. |
Facultatif, mais si défini, le protocole HTTPs est requis. |
Set-Cookie: key=value; SameSite=None; Secure |
L'utilisation du composant OPEN AM
Nous utilisons un composant OPEN AM pour l’authentification par cookie en mode transparent. Et ce sont des loadbalanceurs F5 qui gèrent l'accès aux applications au travers des VIPs paramétrées.
La sécurité bloque le cookie de la vip d’authentification (vu comme un site tiers) de tous les cookies ne provenant pas de la même URL (ceux des serveurs applicatifs et celui de la vip d’authentification).
Donc, le cookie de la VIP d’authentification, créé par le F5 lui-même, oblige un navigateur à revenir vers le même serveur applicatif, ce qui pose problème.
Effectivement, il n’y a pas l’attribut « SameSite » dans le cookie et le comportement par défaut de Chrome est « SameSite = Lax » (autorisation en first-party uniquement). Par conséquent, Chrome bloque la requête car il s’agit d’une utilisation « cross-site » .
Il est donc nécessaire pour nos appli cross-site de définir l’attribut « SameSite = None ; Secure ».
Solution : la mise en place d'une irule
Sur Devcentral, une irule (script F5) permet de prendre en compte différentes versions de navigateurs et de l’utilisation/ajout de l’attribut SameSite :
Après quelques échanges avec les équipes support, nous avons mis en place l’irule proposée par F5 qui était la solution de contournement la plus adaptée à notre contexte en attendant d’upgrader tous nos BIG-IP ASM en v15.
Actuellement, seul le module ASM à partir de la version 13.1.0 permet de spécifier l’attribut SameSite sans utilisation d’une irule, mais un bug est référencé : Bug ID 879841: Domain cookie same-site option is missing the "None" as value in GUI and rest :
Known Affected Versions: 15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4
Fixed In : 16.0.0
Conclusion
Au même titre que Chrome, les versions récentes de navigateurs optent pour la valeur Lax comme valeur par défaut pour mitiger les risques liées aux attaques de type CSRF (cross-site request forgery).
Au niveau navigateur, il faut donc ce 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) et au niveau serveur il faut agir de façon à ne répondre qu’aux requêtes légitimes.
Suite aux remontées des clients, F5 BIG IP a depuis l’année dernière (2020) travaillé à l’implémentation de cette option de gestion de l’attribut SameSite du cookie.
Sur les BIG IP ASM en v13, v14, v15 et v16, il est désormais possible de gérer l’insertion de l’attribut Samesite avec la valeur voulue sans avoir à passer par la mise en place d’une irule.
Sources :
https://support.f5.com/csp/article/K03346798https://www.chromium.org/updates/same-site/faq
