Les cookies HTTP sont-ils spécifiques au port?

355

J'ai deux services HTTP exécutés sur une seule machine. Je veux juste savoir s'ils partagent leurs cookies ou si le navigateur fait la distinction entre les deux sockets serveur.

guerda
la source

Réponses:

329

La spécification de cookie actuelle est la RFC 6265 , qui remplace la RFC 2109 et la RFC 2965 (les deux RFC sont désormais marquées comme "historiques") et formalise la syntaxe pour les utilisations réelles des cookies. Il indique clairement:

  1. introduction

...

Pour des raisons historiques, les cookies contiennent un certain nombre de problèmes de sécurité et de confidentialité. Par exemple, un serveur peut indiquer qu'un cookie donné est destiné à des connexions "sécurisées", mais l'attribut Secure ne fournit pas d'intégrité en présence d'un attaquant réseau actif. De même, les cookies pour un hôte donné sont partagés entre tous les ports de cet hôte, même si la «politique d'origine identique» utilisée par les navigateurs Web isole le contenu récupéré via différents ports.

Et aussi:

8.5. Faible confidentialité

Les cookies n'offrent pas d'isolement par port . Si un cookie est lisible par un service s'exécutant sur un port, le cookie est également lisible par un service s'exécutant sur un autre port du même serveur. Si un cookie est accessible en écriture par un service sur un port, le cookie est également accessible en écriture par un service exécuté sur un autre port du même serveur. Pour cette raison, les serveurs NE DEVRAIENT PAS à la fois exécuter des services se méfiant mutuellement sur différents ports du même hôte et utiliser des cookies pour stocker des informations sensibles pour la sécurité.

Rémy Lebeau
la source
129

Selon la RFC2965 3.3.1 (qui peut ou non être suivie par les navigateurs), à moins que le port ne soit explicitement spécifié via le portparamètre de l'en- Set-Cookietête, les cookies peuvent ou non être envoyés à n'importe quel port.

Le manuel de sécurité du navigateur de Google indique: par défaut, la portée des cookies est limitée à toutes les URL du nom d'hôte actuel - et n'est pas liée aux informations de port ou de protocole. et quelques lignes plus tard Il n'y a aucun moyen de limiter les cookies à un seul nom DNS uniquement [...] de même, il n'y a aucun moyen de les limiter à un port spécifique. ( De plus, gardez à l' esprit que IE ne les numéros de port de facteurs ne sont pas dans sa politique d'origine du tout .)

Il ne semble donc pas sûr de s'appuyer sur un comportement bien défini ici.

Tgr
la source
75
La RFC 6265 , qui remplace la RFC 2965, élimine le Portparamètre dans l'en- Set-Cookietête (car presque personne ne l'a réellement utilisé dans la pratique), et rend très explicite que les cookies sur le même hôte NE SONT PLUS différenciables par les ports.
Remy Lebeau
5
IE 9 n'enverra même pas le cookie sur les demandes suivantes si le domaine a un port dedans
axk
3
Y a-t-il un navigateur qui envisage toujours le port dans le SOP de ses cookies?
Bertuz
5
Chrome ne définira même pas le cookie s'il a le domaine a un port.
Pim Heijden
76

C'est une très vieille question, mais j'ai pensé ajouter une solution de contournement que j'ai utilisée.

J'ai deux services en cours d'exécution sur mon ordinateur portable (un sur le port 3000 et l'autre sur 4000). Lorsque je sautais entre ( http://localhost:3000et http://localhost:4000), Chrome passait dans le même cookie, chaque service ne comprenait pas le cookie et n'en générait pas un nouveau.

J'ai constaté que si j'y accédais http://localhost:3000et http://127.0.0.1:4000, le problème disparaissait puisque Chrome conservait un cookie pour localhost et un pour 127.0.0.1.

Encore une fois, personne ne s'en soucie peut-être à ce stade, mais cela a été facile et utile à ma situation.

Tapoter
la source
1
Oui, car les cookies sont associés à des noms d'hôte / domaine, donc un cookie localhostne peut pas être partagé avec 127.0.0.1et vice versa. Mais les cookies sur le même hôte / domaine, quel que soit le port, peuvent être partagés.
Remy Lebeau
3
Bien sûr qu'ils le font. J'utilise (et probablement des millions d'autres développeurs) localhost pour tester tout le temps. À moins que le port ajouté ne fasse la différence: localhost: 8080
David Balažic
53
De plus, vous pouvez utiliser 127.0.0.1, 127.0.0.2, 127.0.0.3 etc ... ils signifient tous localhost.
David Balažic
3
Je ne peux pas voter contre, car cela ne répond pas à la question, mais c'est un excellent conseil, merci!
Martin T.13
2
Si vous êtes prêt à modifier votre fichier hosts (/ etc / hosts sous Unix), vous pouvez avoir autant de noms significatifs que vous le souhaitez pour localhost.
Silas S. Brown
20

Il s'agit d'une grande zone grise dans le cookie SOP (même politique d'origine).

Théoriquement, vous pouvez spécifier le numéro de port dans le domaine et le cookie ne sera pas partagé. En pratique, cela ne fonctionne pas avec plusieurs navigateurs et vous rencontrerez d'autres problèmes. Cela n'est donc possible que si vos sites ne sont pas destinés au grand public et que vous pouvez contrôler les navigateurs à utiliser.

La meilleure approche consiste à obtenir 2 noms de domaine pour la même IP et à ne pas compter sur les numéros de port pour les cookies.

Codeur ZZ
la source
9
Ce n'est plus une zone grise. La RFC 6265 , qui est la norme actuelle en matière de cookies, élimine toute confusion à ce sujet en éliminant simplement la possibilité de séparer les cookies sur le même hôte en utilisant différents ports.
Remy Lebeau
18

Une autre façon de contourner le problème est de faire en sorte que le nom du cookie de session soit lié au port. Par exemple:

  • mysession8080 pour le serveur fonctionnant sur le port 8080
  • mysession8000 pour le serveur fonctionnant sur le port 8000

Votre code pourrait accéder à la configuration du serveur Web pour savoir quel port votre serveur utilise et nommer le cookie en conséquence.

Gardez à l'esprit que votre application recevra les deux cookies, et vous devez demander celui qui correspond à votre port.

Il n'est pas nécessaire d'avoir le numéro de port exact dans le nom du cookie, mais c'est plus pratique.

En général, le nom du cookie peut coder tout autre paramètre spécifique à l'instance de serveur que vous utilisez, il peut donc être décodé par le bon contexte.

Manolis M. Tsangaris
la source
9

Dans IE 8, les cookies (vérifiés uniquement par rapport à localhost) sont partagés entre les ports. En FF 10, ils ne le sont pas.

J'ai publié cette réponse afin que les lecteurs aient au moins une option concrète pour tester chaque scénario.

Jeb
la source
4

Je rencontrais un problème similaire en exécutant (et en essayant de déboguer) deux applications Django différentes sur la même machine.

Je les exécutais avec ces commandes:

./manage.py runserver 8000
./manage.py runserver 8001

Lorsque je me suis connecté dans le premier, puis dans le second, je me suis toujours déconnecté du premier et vice-versa.

J'ai ajouté ceci sur mon / etc / hosts

127.0.0.1    app1
127.0.0.1    app2

Ensuite, j'ai démarré les deux applications avec ces commandes:

./manage.py runserver app1:8000
./manage.py runserver app2:8001

Problème résolu :)

Andrea Grandi
la source
4
vous pouvez probablement l'utiliser 127.0.0.1:8000pour un, localhost:8000pour une seconde, et peut-être ::1:8000(peut-être [::1]:8080) pour un troisième sans jamais avoir à toucher le fichier hosts.
Travis Watson
1
vous pouvez le mettre en une seule ligne:::1 app1 app2 app3 app4 app5 appN
aéroson