J’adore quand vous mangez votre propre nourriture pour chien !!!.
Les navigateurs modernes, sans en mentionner aucun en particulier (comme Chrome), sont de plus en plus pointilleux en ce qui concerne les paramètres de sécurité des cookies.
Un exemple est le paramètre de cookie SameSite. Par exemple, s’il n’est pas présent dans Chrome, il utilisera sa méthode par défaut, SameSite=Lax.
Mais que se passe-t-il si vous ne le souhaitez pas ? La réponse est de modifier le code de votre application pour refléter le paramètre que vous souhaitez utiliser. Mais que se passe-t-il si vous ne pouvez pas le faire facilement ? Il peut s’agir d’une application ancienne.
La solution consiste à utiliser les fonctions de changement de contenu de l’EdgeADC flightPATH.
Le fameux problème de WordPress WooCommerce fonctionnant dans une Iframe
Nous avons eu un problème avec une application WordPress que nous utilisons et qui s’exécute dans une Iframe. (Ne demandez pas pourquoi.)
L’application utilisait des cookies de session pour lesquels le paramètre SameSite n’était pas défini.
L’application fonctionne dans un système WordPress par défaut fourni dans un conteneur Docker.
Nous avons étudié plusieurs façons de résoudre ce problème, mais nos modifications n’ont pas fonctionné correctement sur tous les cookies, et nous avons donc décidé d’essayer de résoudre le problème à l’aide de flightPATH.
Voici donc ce que nous avons fait.
Nous avons créé une règle flightPATH pour ajouter SameSite=none aux trois cookies incriminés, comme indiqué ci-dessous.
La première règle flightPATH que nous allons créer est la suivante :
Ensuite, nous allons créer le second.
Enfin, nous créons le dernier. Celui-ci a une définition légèrement différente, comme vous pouvez le voir. Nous avons ajouté un joker (*) car nous ne savons pas quelle est cette valeur, puisque WordPress / WooCommerce attribue une valeur aléatoire.
À ce stade, vous vous dites : « Hé ! ce n’est pas sûr lorsqu’un caractère générique est utilisé ! Nous comprenons que le site est légèrement moins sûr, mais.. :
- Tout fonctionne en HTTPS
- Nous utilisons un pare-feu applicatif
- Il est renforcé par le fait qu’il s’agit d’un système d’exploitation conteneurisé et que les fichiers clés sont immuables.
Et si vous avez besoin d’un rappel sur SameSite…
Quelle est la configuration de SameSite pour les cookies ?
Le paramètre SameSite Cookie permet de contrôler l’envoi de cookies avec les requêtes intersites, ce qui contribue à réduire le risque d’attaques par falsification de requêtes intersites (CSRF). Voici comment cela fonctionne :
Qu’est-ce que les requêtes intersites ?
Les requêtes intersites sont des requêtes effectuées d’un site web à un autre. Par exemple, si vous êtes connecté à une application et que vous cliquez sur un lien vers un article d’actualité, il s’agit d’une requête intersite. En d’autres termes, il s’agit d’une requête qui relie un site à un autre.
Qu’est-ce que le paramètre SameSite ?
Le paramètre SameSite est un attribut de cookie qui peut être utilisé pour contrôler si un cookie est envoyé avec les requêtes intersites. Trois valeurs sont possibles pour le paramètre SameSite :
- SameSite=Strict : Les cookies ne sont envoyés qu’avec des demandes adressées au même site que celui qui les a créés.
- SameSite=Lax : Les cookies sont envoyés avec des requêtes au même site que celui qui les a créés, ainsi qu’avec des requêtes à des sites tiers intégrés dans la même page, par exemple dans une iFrame.
- SameSite=None : Les cookies sont envoyés avec toutes les requêtes, quel que soit le site qui les a créés.
Pourquoi le paramètre SameSite est-il important ?
Le paramètre SameSite est important car il permet de réduire le risque d’attaques Cross-Site Request Forgery (CSRF). Les attaques CSRF sont un type de cyberattaque qui exploite le fait que le navigateur d’un utilisateur est déjà connecté à un site web. Dans le cadre d’une attaque CSRF, un pirate peut inciter un utilisateur à envoyer une requête à un site web auquel il est connecté, même si l’utilisateur n’a pas l’intention de le faire. Cela peut permettre à l’attaquant de voler les données de l’utilisateur ou d’effectuer d’autres actions malveillantes.
