Les cookies du même site seront-ils une protection suffisante contre CSRF et XSS?
Je dois dire que j'aime cette idée et il semble qu'elle apportera une nouvelle forme de protection contre CSRF et XSS ou au moins elle réduira ces attaques.
Alors, quelle sera l'efficacité de cette protection?
SameSite-cookies est un mécanisme permettant de définir comment les cookies doivent être envoyés sur les domaines. Il s'agit d'un mécanisme de sécurité développé par Google et actuellement présent dans Chrome-dev (51.0.2704.4) . Les cookies SameSite ont pour but [d'essayer] d'empêcher les attaques CSRF et XSSI. Vous pouvez lire le projet ici. (Source)
Tout d'abord, une définition de Chrome :
Les cookies du même site (née "First-Party-Only" (née "First-Party")) permettent aux serveurs d'atténuer le risque d'attaques CSRF et de fuite d'informations en affirmant qu'un cookie particulier ne doit être envoyé qu'avec des demandes initiées par le même domaine enregistrable.
Alors contre quoi cela protège-t-il?
CSRF?
Les cookies du même site peuvent empêcher efficacement les attaques CSRF. Pourquoi?
Si vous définissez le cookie de session sur le même site, il ne sera envoyé que si une demande émane de votre site. Donc, une attaque CSRF standard où l'attaquant attire la victime sur le site http://malicious.com qui envoie une demande à http://bank.com/transfer.php?amount=10000&receiver=evil_hacker ne fonctionnera pas. Depuis malicious.com n'est pas la même origine que bank.com, le navigateur n'enverra pas le cookie de session et transfer.php s'exécutera comme si la victime n'était pas connectée.
Ceci est très similaire à la façon dont la définition d'un X-Csrf-Token L'en-tête HTTP vous protège contre CSRF - là encore, quelque chose n'est envoyé que si la demande émane de votre domaine. La propriété du même site transforme votre cookie de session en un jeton CSRF.
Donc, le problème est résolu? Eh bien, en quelque sorte. Il y a quelques mises en garde:
- Cela ne fonctionnera que pour les navigateurs qui implémentent cette fonctionnalité. Jusqu'à présent, très peu le font. À moins que vous ne vouliez jeter tous ceux qui utilisent un navigateur légèrement plus ancien sous le bus, vous devrez toujours implémenter un jeton CSRF à l'ancienne.
- Si vous avez besoin d'un contrôle plus fin, cela ne suffira pas. Si vous exécutez un système qui affiche du contenu utilisateur non fiable, comme un forum, vous ne voulez pas que les demandes provenant de messages utilisateur soient traitées comme valides. Si quelqu'un publie un lien vers
http://myforum.com/?action=delete_everythingvous ne voulez pas que cela supprime quoi que ce soit juste parce qu'un utilisateur clique dessus. Avec un jeton CSRF traditionnel, vous pouvez contrôler exactement quand il est utilisé. Avec un cookie du même site, vous ne pouvez pas. - Les mêmes mises en garde anciennes que pour les protections CSRF à l'ancienne s'appliquent toujours. Si vous avez une vulnérabilité XSS, aucune protection CSRF dans ce monde ne vous sauvera.
Cela dit, le cookie du même site est toujours une bonne chose qui devrait être utilisé avec les défenses traditionnelles comme défense en profondeur.
XSS et XSSI?
Le cookie du même site ne fait rien pour vous protéger contre les attaques XSS ordinaires. Si un pirate parvient à tromper votre site pour faire écho au script de l'URL de votre site, il sera exécuté comme provenant de votre origine (après tout, c'est le cas), et donc les cookies de session seront toujours envoyés avec toutes les demandes du script injecté fait à votre domaine.
Si vous lisez attentivement la citation dans votre article, vous verrez qu'elle indique XSSI avec un I à la fin, et non XSS. Le I signifie inclusion, et XSSI est lié à, mais différent de XSS. Ici est une bonne explication de XSSI et comment il diffère de XSS:
XSSI est une forme de XSS qui tire parti du fait que les navigateurs n'empêchent pas les pages Web d'inclure des ressources telles que des images et des scripts, qui sont hébergés sur d'autres domaines et serveurs. [...] Par exemple, si le site de Bank ABC a un script qui lit les informations de compte privé d'un utilisateur, un pirate pourrait inclure ce script dans son propre site malveillant (www.fraudulentbank.com) pour extraire des informations des serveurs de Bank ABC chaque fois qu'un client de Bank ABC visite le site du pirate.
Les cookies du même site vous protègent contre XSSI, car un cookie de session ne serait pas envoyé avec la demande de script et ne retournerait donc aucune information sensible. Cependant, pour XSS ordinaire, cela ne fait aucune différence.
Cela dépend des navigateurs que vous souhaitez prendre en charge et de la configuration actuelle de votre site.
Si vous ne prenez en charge que les navigateurs prenant en charge cette fonctionnalité, cela devrait suffire si vous êtes prêt à:
- Ne pas envoyer de cookies avec une navigation de haut niveau (cela est assez restrictif car vous ne pouvez pas créer de lien vers des pages connectées en externe)
- Assurez-vous qu'aucune opération n'utilise
GET(ou toute méthode sûre ) pour effectuer une opération, sinon vous vous ouvrez pour relier les attaques comme dans la réponse précédente
Si vous pouvez vivre sans navigation de haut niveau vers des pages connectées à partir de sites externes, alors SameSite: 'strict' peut convenir, cette option fait que le cookie donné n'est pas envoyé avec toute demande inter-origine (y compris les liens de clic, etc.).
Si vous avez besoin de créer un lien vers des pages connectées à partir de sites externes, vous devez vous assurer qu'aucun changement observable ne se produira à partir d'un GET (ou toute méthode sûre ) sur le serveur et doit utiliser SameSite: 'lax' au lieu. Si vous pouvez garantir cette contrainte, même les liens soumis par l'utilisateur doivent être protégés (de toute façon contre les attaques CRSF).
S'assurer que l'une de ces contraintes n'est probablement pas anodin dans une base de code existante (en plus de l'exigence du navigateur moderne), donc je ne recommanderais pas de supprimer les jetons CSRF si vous les utilisez déjà, car beaucoup d'endroits abusent encore GET pour déclencher des opérations.
Si vous démarrez un nouveau projet et que vous ne prévoyez pas de prendre en charge des navigateurs qui ne prennent pas en charge la fonctionnalité, il vaut probablement la peine d'envisager, car il ne s'agit essentiellement que d'une seule ligne de code, assurez-vous simplement de connaître 'lax' et 'strict' modes et quelles restrictions vous devrez respecter avec les deux.
En ce qui concerne SameSite: 'strict': Si vous utilisez SameSite: 'strict' et un utilisateur clique sur un lien externe dans une partie restreinte du site, puis pourrait afficher un écran de démarrage lui demandant s'il souhaite continuer. Je recommanderais fortement ceci si les ressources ne sont pas destinées à être liées à l'extérieur, auquel cas un lien est susceptible d'être une attaque/un truc.
En ayant un tel écran de démarrage si l'utilisateur choisit de continuer, il n'aura pas besoin de se connecter à nouveau car cliquer sur continuer sur votre site enverra SameSite- cookies car il s'agit bien de la même origine.
Si vous souhaitez que la redirection se fasse automatiquement, vous pouvez également simplement ajouter un Refresh: 0 en-tête pour les pages dont vous savez qu'elles sont sûres (ce qui est également une excellente occasion de vérifier si une page donnée est réellement sûre pour être liée à l'extérieur, si pas revenir à l'écran de démarrage mentionné ci-dessus). L'inconvénient majeur de cette vs SameSite: 'lax' est que vous finissez par répéter la navigation deux fois.