Un cookie sécurisé peut-il être défini à partir d'une connexion HTTP non sécurisée? Si oui, pourquoi est-il autorisé?
En référence à certains documents de sécurité que j'ai lus, j'ai découvert qu'un cookie avec le jeu d'indicateurs sécurisé ne peut être envoyé que par le client via des connexions qui utilisent HTTPS, pas HTTP, mais le cookie lui-même peut être défini à partir du serveur avec un serveur sécurisé indicateur d'une connexion HTTP non sécurisée. Pourquoi est-ce autorisé?
Les cookies sécurisés peuvent être définis sur des canaux non sécurisés (par exemple HTTP) conformément à section 4.1.2.5 de la RFC 6265 . Il mentionne explicitement que l'indicateur sécurisé ne fournit que la confidentialité et non l'intégrité, car un cookie marqué sécurisé peut toujours être défini à partir d'un canal non sécurisé, écrasant toute valeur précédemment définie (via un canal sécurisé ou autre):
L'attribut Secure limite la portée du cookie aux canaux "sécurisés" (où "sécurisé" est défini par l'agent utilisateur). Lorsqu'un cookie possède l'attribut Secure, l'agent utilisateur n'inclura le cookie dans une demande HTTP que si la demande est transmise sur un canal sécurisé (généralement HTTP sur Transport Layer Security (TLS) [RFC2818]).
Bien qu'il semble utile pour protéger les cookies contre les attaquants réseau actifs, l'attribut Secure protège uniquement la confidentialité du cookie. Un attaquant du réseau actif peut écraser les cookies sécurisés d'un canal non sécurisé, perturbant leur intégrité (voir la section 8.6 pour plus de détails).
Section 8.6 donne plusieurs exemples, mais je ne les copierai pas ici en raison de la longueur de la section.
Quant à savoir pourquoi, il n'y a pas de cas d'utilisation clair que je sache. Je soupçonne que le RFC a été écrit dans la perspective d'avoir uniquement l'objectif de protéger la confidentialité, et donc d'empêcher les cookies marqués sécurisés d'être acceptés lorsqu'ils sont définis sur HTTP était une restriction inutile pour cet objectif. Je suppose que la justification était "si nous fournissons cette fonctionnalité, les gens peuvent supposer que l'intégrité des cookies est protégée par l'indicateur sécurisé, et nous ne voulons pas que les gens émettent cette hypothèse".
Cela dit, le fait que les données puissent être définies sur un canal non sécurisé nie quelque peu le concept de l'envoi de la valeur du cookie uniquement sur un canal sécurisé, de sorte que la sensibilité de la décision est discutable. Le RFC mentionne au moins que vous perdez la confidentialité si vous faites cela.
Citant rfc2965 qui était obsolète par rfc6265 que Polynomial a mentionné:
Sécurise
OPTIONNEL. L'attribut Secure (sans valeur) demande à l'agent utilisateur d'utiliser uniquement des moyens sécurisés (non spécifiés) pour contacter le serveur Origin chaque fois qu'il renvoie ce cookie, afin de protéger la confidentialité et l'authenticité des informations contenues dans le cookie.
L'agent utilisateur (éventuellement avec interaction de l'utilisateur) PEUT déterminer le niveau de sécurité qu'il considère approprié pour les cookies "sécurisés". L'attribut Secure doit être considéré comme un conseil de sécurité du serveur à l'agent utilisateur, indiquant qu'il est dans l'intérêt de la session de protéger le contenu du cookie. Lorsqu'il envoie un cookie "sécurisé" à un serveur, l'agent utilisateur DEVRAIT utiliser au moins le même niveau de sécurité que celui utilisé lors de la réception du cookie du serveur.
(c'est moi qui souligne)
Mon interprétation est qu'ils voulaient que le serveur s'occupe de la sécurité sur le chemin du client et ait un moyen de dire au client qu'il devrait faire de même.
En effet, le résultat est douteux comme mentionné dans la réponse de Polynomial.
La question de savoir où dans le RFC cela est documenté a reçu une réponse suffisante.
Mais pourquoi?
Comme pour les autres fonctionnalités de sécurité, cette fonctionnalité particulière ("cookie sécurisé") n'a qu'un et un seul objectif: éviter qu'un spectateur/renifleur ne récupère votre cookie.
Il n'est pas censé être une panacée contre tous les types d'attaques de cookies possibles, mais seulement cette attaque très spécifique:
- Le navigateur présente certaines informations d'identification à un serveur (via une connexion sécurisée).
- Le serveur crée une session et vous remet le cookie (via une connexion sécurisée).
- Le navigateur renvoie le cookie de session avec d'autres demandes (via des connexions sécurisées).
- Un attaquant parvient à faire en sorte que votre navigateur établisse une connexion non sécurisée avec le serveur d'origine.
- L'attaquant renifle la requête HTTP et dispose désormais du cookie.
On peut supposer que 1., 2. et 3. sont plus difficiles à attaquer que 4./5.
L'utilisateur peut être formé pour vérifier qu'un formulaire de connexion affiche une URL HTTPS et un "drapeau vert" à côté de l'URL, selon le navigateur. Au moment où vous saisissez vos informations d'identification, un utilisateur avisé peut raisonnablement s'attendre à ce qu'il fasse attention à l'URL, ces jours-ci. (C'est ainsi que fonctionne l'attaque de courrier indésirable habituelle, en les trompant pour entrer leur nom d'utilisateur/pw à une URL arbitraire - un sujet pour un autre jour.)
Est très difficile à attaquer sauf si le serveur est bogué: le serveur sait très bien si la connexion est HTTP ou HTTPS, donc ne créera une session que si elle vient via HTTPS. Un système vraiment important ferait mieux de ne pas écouter sur HTTP de toute façon.
Les requêtes régulières n'ont pas besoin d'être attaquées. Ils passeront par une connexion HTTPS sécurisée et tout ira bien.
Il est assez facile de connecter un navigateur à des URL arbitraires - il suffit de placer une balise quelque part ou d'en déclencher quelques-uns AJAX si vous le pouvez. Et certains serveurs peuvent décharger des images statiques et ainsi une connexion non sécurisée pour enregistrer CPU, donc un attaquant n'aura rien à faire du tout.
Ainsi, ce scénario est évité par le cookie sécurisé. Le cookie ne passera que sur HTTPS, donc l'attaquant ne peut pas renifler le cookie.
Bien sûr, il existe de nombreux autres vecteurs d'attaque pour toujours obtenir le cookie (man-in-the-middle contre HTTPS; le lire à la place par Javascript (empêché par le drapeau "httponly"); faire une demande HTTPS à un site Web de la attaquant avec un cookie trop laxiste (empêché par des politiques de même origine ou en définissant correctement le domaine du cookie côté serveur) et ainsi de suite).
Notez qu'il est difficile de se protéger contre 4. Il est assez facile de demander à un navigateur de demander n'importe quelle URL arbitraire. Notez que vous n'avez pas besoin de demander une URL valide, vous avez seulement besoin du navigateur pour envoyer la requête HTTP (y compris le cookie); vous ne vous souciez pas du résultat, et il est impossible pour le serveur d'empêcher le navigateur d'envoyer la demande non sécurisée en premier lieu, sauf en n'écoutant pas du tout sur HTTP, c'est-à-dire en n'ayant pas le port TCP/IP ouvert. Mais même cela ne suffit pas; si l'utilisateur passe par un proxy (commun dans les intranets d'entreprise), le navigateur enverra toujours la requête HTTP au proxy (via HTTP), et un attaquant qui renifle entre le navigateur et le proxy a toujours le cookie, même si le le serveur réel n'a jamais accepté la connexion TCP/IP.
TL; DR
Le cookie "sécurisé" est destiné à protéger contre un problème très spécifique qui, autrement, serait impossible à protéger.
Il n'est pas destiné à se protéger contre un serveur bogué, paresseux ou mal configuré qui envoie le cookie sur un canal non sécurisé en premier lieu.
Le faire comme ça (c'est-à-dire une fonctionnalité contre une attaque spécifique) est une bonne chose, et c'est ce que font la plupart des fonctionnalités de sécurité. On s'attend à ce que vous réfléchissiez aux types d'attaques contre lesquels une fonctionnalité comme celle-ci pas protège; et ce raisonnement est assez facile car la portée de la fonctionnalité est limitée.
Actuellement sur le Web, nous devons accepter que de nombreux navigateurs et leurs utilisateurs tentent généralement d'accéder aux ressources Web via des connexions non sécurisées (HTTP).
En tant que tel, il y a un peu de mou dans le RFC en ce qui concerne le moment où les cookies avec l'indicateur de cookie sécurisé peuvent être définis. Plus précisément, oui, il est autorisé de définir des cookies avec l'indicateur Secure même si vous le faites via une connexion HTTP.
L'indicateur Secure ne peut que renforcer la sécurité du serveur, il n'y a donc aucune raison d'empêcher cela de fonctionner d'un point de vue technique ou de sécurité, bien que cela ne signifie pas que c'est une bonne idée de le faire. D'un point de vue efficacité, il peut être raisonnable de répondre aux demandes de connexion avec les informations d'authentification nécessaires (dans un cookie avec l'indicateur Secure), puis de rediriger l'utilisateur vers HTTPS où le nouveau cookie d'authentification sera réellement envoyé.
À ce stade, il est possible que des en-têtes HSTS aient également été envoyés, de sorte que le navigateur n'essayera plus d'utiliser HTTP à l'avenir, ce qui atténuera les futures attaques par écrasement des cookies.
Maintenant, vous auriez raison de penser qu'à ce stade, un attaquant aurait pu intercepter ces données de cookie initiales et donc les utiliser pour usurper l'identité de l'utilisateur. C'est loin d'être idéal. Mais cela dépend aussi de l'utilisateur se connectant au site via HTTP et recevant un en-tête HSTS sans qu'un attaquant altère/supprime cet en-tête. C'est pourquoi nous avons le préchargement HSTS. À cette fin, le préchargement du drapeau sécurisé par cookie peut être un concept intéressant!
On peut supposer qu'après avoir configuré le cookie, le seul risque pour l'utilisateur en termes d'attaques réseau est que le navigateur ne dispose pas d'instructions HSTS pour le domaine en question. Ensuite, un attaquant oblige l'utilisateur à se désauthentifier (peut-être en bloquant le trafic SSL et en attendant que l'utilisateur essaie de taper à nouveau l'adresse où il initiera très probablement une connexion HTTP), intercepte les informations d'authentification et/ou le jeton, supprime la sécurité drapeau et assure qu'une redirection HTTPS ne se produit pas pour le client (tout en négociant potentiellement cela vers le serveur si nécessaire).
Cela peut être utile pour la sécurité dans certaines situations, essentiellement si votre connexion Internet a été altérée en raison d'un manque de cryptage HTTPS. Cependant, dans la plupart des cas, l'injection de cookies est faible sur la liste des préoccupations par rapport aux autres fonctionnalités compromises.
Le protocole HTTP n'offre actuellement aucun moyen au client de fournir des métadonnées sur le cookie.
Par exemple, si un cookie est défini avec path=/, puis un cookie est défini avec path=/narrow-scope Ensuite, si vous visitez le site, visitez un /narrow-scope URL, les deux cookies sont envoyés: Cookie: name=valueA, name=valueB.
Le serveur ne peut pas dire quel chemin spécifique a été utilisé pour chaque cookie. Seulement que les métadonnées entre elles sont différentes sinon elles seraient considérées comme le même cookie (ayant le même name)
De même, il n'est pas possible pour les cookies d'être marqués comme si l'indicateur Secure est défini ou HttpOnly. Aucune métadonnée n'est transmise du client au serveur.
Afin d'empêcher une page HTTP de définir un cookie sécurisé, il y aurait deux possibilités:
Tous les cookies fournis par HTTP ne sont pas accessibles lors de la visite de la page HTTPS. Ce serait une rupture importante dans la compatibilité.
Ou Les métadonnées sont ajoutées à la valeur
Cookiefournie par le client afin que le serveur puisse en savoir plus. Par exemple, le serveur peut souhaiter distinguer les cookies définis via JavaScript. Ou comme vous le dites, que ce soit défini dans HTTPS ou HTTP.Ce serait un grand changement, et il n'y a pas beaucoup de demande pour cela. Dans la plupart des cas, il ne correspond pas non plus à une fonction de sécurité.
En fin de compte, la bonne solution consiste à forcer les utilisateurs à utiliser les connexions HTTPS .