En quoi l'absence du drapeau de cookie "SameSite" est-elle un risque?
De nos jours, les cookies peuvent avoir des drapeaux HTTPOnly, Secure et SameSite. Les objectifs des indicateurs HTTPOnly et Secure sont assez clairs. Mais qu'est-ce que les scripts SameSite empêchent exactement et comment?
De plus, à quoi ressemblerait un scénario "d'attaque" ou de "mauvaise utilisation" réussi lorsque l'indicateur SameSite n'est pas utilisé?
Les objectifs du drapeau SameSite sont:
- empêcher les attaques de synchronisation d'origine croisée (voir par exemple ici )
- empêcher l'inclusion du script Cross Origin (voir ici )
- empêcher CSRF: les cookies SameSite ne sont envoyés que si le site d'où provient la demande est dans la même origine que le site cible (en mode strict pour GET et POST, en mode laxiste uniquement pour POST) .
- protection limitée de la vie privée
La réponse réelle devrait être, comme toujours: cela dépend de votre scénario d'utilisation.
La valeur Strict empêchera le cookie d'être envoyé par le navigateur au site cible dans tous les contextes de navigation intersite, même en suivant un lien régulier. Par exemple, pour un site Web de type GitHub, cela signifierait que si un utilisateur connecté suit un lien vers un projet GitHub privé publié sur un forum de discussion d'entreprise ou par e-mail, GitHub pas recevra le cookie de session et l'utilisateur ne pourra pas accéder au projet. Cependant, un site Web de banque ne souhaite probablement pas autoriser la liaison de pages transactionnelles à partir de sites externes, de sorte que l'indicateur Strict serait le plus approprié ici.
La valeur par défaut Lax fournit un équilibre raisonnable entre sécurité et convivialité pour les sites Web qui souhaitent maintenir la session de connexion de l'utilisateur après que l'utilisateur arrive à partir d'un lien externe. Dans le scénario GitHub ci-dessus, le cookie de session serait autorisé lorsque vous suivez un lien régulier à partir d'un site Web externe tout en le bloquant dans les méthodes de demande sujettes à CSRF (par exemple POST).