Les cookies HTTP sont-ils spécifiques au port?
J'ai deux services HTTP s'exécutant sur une machine. Je veux juste savoir s'ils partagent leurs cookies ou si le navigateur fait la distinction entre les deux sockets serveur.
La spécification de cookie actuelle est RFC 6265 , qui remplace RFC 2109 et RFC 2965 (les deux RFC sont maintenant marqués comme "historiques") et officialise le syntaxe pour les utilisations réelles des cookies. Il est clairement indiqué:
- 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 garantit pas l'intégrité en présence d'un attaquant actif du réseau. De même, les cookies pour un hôte donné sont partagés sur tous les ports de cet hôte, même si la "règle de même origine" utilisée par les navigateurs Web isole le contenu récupéré via différents ports.
Et aussi:
8.5 Faible confidentialité
Les cookies ne fournissent pas d'isolation par port . Si un cookie est lisible par un service exécuté sur un port, il est également lisible par un service exécuté sur un autre port du même serveur. Si un cookie est accessible en écriture par un service sur un port, il 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 exécuter des services mutuellement méfiants sur différents ports du même hôte et utiliser des cookies pour stocker des informations sensibles.
Selon RFC2965 3.3.1 (éventuellement suivi par les navigateurs), à moins que le port ne soit explicitement spécifié via le paramètre port du Set-Cookie en-tête, les cookies peuvent être ou ne pas être envoyés à n’importe quel port.
Le Manuel de sécurité du navigateur de Google indique: par défaut, la portée du cookie est limitée à toutes les URL du nom d'hôte actuel - et n'est pas liée au port ou au protocole. et quelques lignes plus tard Il n’existe aucun moyen de limiter les cookies à un seul nom DNS [...] de même, il n’existe aucun moyen de limiter (rappelez-vous également que IE ne prend pas en compte les numéros de port dans sa politique de même origine du tout .)
Il ne semble donc pas prudent de s’appuyer sur un comportement bien défini.
C'est une question très ancienne mais j'ai pensé ajouter une solution de contournement que j'ai utilisée.
J'ai deux services fonctionnant sur mon ordinateur portable (un sur le port 3000 et l'autre sur le port 4000). Lorsque je sautais entre (http://localhost:3000 et http://localhost:4000), Chrome passait dans le même cookie, chaque service ne pouvait pas comprendre le cookie et en générer un nouveau.
J'ai constaté que si j'accédais à http://localhost:3000 et à 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 pour le moment, mais c’était facile et utile pour ma situation.
Il s’agit d’une grande zone grise dans le cookie SOP (stratégie d’origine identique).
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 faisable que si vos sites ne sont pas destinés au grand public et vous pouvez contrôler les navigateurs à utiliser.
La meilleure approche consiste à obtenir 2 noms de domaine pour la même adresse IP et à ne pas compter sur les numéros de port pour les cookies.
Une autre façon de contourner le problème consiste à associer le nom du cookie de session au port. Par exemple:
- mysession808 pour le serveur fonctionnant sur le port 8080
- mysession80 pour le serveur fonctionnant sur le port 8000
Votre code pourrait accéder à la configuration du serveur Web pour connaître le port utilisé par votre serveur et attribuer un nom au cookie en conséquence.
Gardez à l'esprit que votre application recevra les deux cookies et que vous devez demander celui qui correspond à votre port.
Il n’est pas nécessaire d’indiquer le numéro de port exact dans le nom du cookie, mais c’est plus pratique.
En règle générale, 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 contexte approprié.
Dans IE 8, les cookies (vérifiés uniquement auprès de localhost) sont partagés entre les ports. Dans 10 francs, ils ne le sont pas.
J'ai posté cette réponse afin que les lecteurs disposent d'au moins une option concrète pour tester chaque scénario.
Je rencontrais un problème similaire lors de l'exécution (et du débogage) de deux applications Django différentes sur le même ordinateur.
Je les exécutais avec ces commandes:
./manage.py runserver 8000
./manage.py runserver 8001
Quand je me suis connecté au premier et ensuite au 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 :)
C'est optionnel.
Le port peut être spécifié pour que les cookies puissent être spécifiques au port. Ce n'est pas nécessaire, le serveur Web/l'application doit s'en occuper.
Source: article de Wikipedia allemand , RFC2109 , chapitre 4.3.1