Antworten:
Die aktuelle Cookie-Spezifikation ist RFC 6265 , die RFC 2109 und RFC 2965 ersetzt (beide RFCs sind jetzt als "Historisch" gekennzeichnet) und die Syntax für die reale Verwendung von Cookies formalisiert. Darin heißt es eindeutig:
- Einführung
...
Aus historischen Gründen enthalten Cookies eine Reihe von Sicherheits- und Datenschutzproblemen. Ein Server kann beispielsweise angeben, dass ein bestimmtes Cookie für "sichere" Verbindungen vorgesehen ist, das Attribut "Sicher" jedoch bei Vorhandensein eines aktiven Netzwerkangreifers keine Integrität bietet. In ähnlicher Weise werden Cookies für einen bestimmten Host von allen Ports auf diesem Host gemeinsam genutzt, obwohl die übliche "Richtlinie gleichen Ursprungs", die von Webbrowsern verwendet wird, Inhalte isoliert, die über verschiedene Ports abgerufen werden.
Und auch:
8.5. Schwache Vertraulichkeit
Cookies bieten keine Isolierung nach Port . Wenn ein Cookie von einem Dienst gelesen werden kann, der auf einem Port ausgeführt wird, kann das Cookie auch von einem Dienst gelesen werden, der auf einem anderen Port desselben Servers ausgeführt wird. Wenn ein Cookie von einem Dienst an einem Port geschrieben werden kann, kann das Cookie auch von einem Dienst geschrieben werden, der auf einem anderen Port desselben Servers ausgeführt wird. Aus diesem Grund sollten Server NICHT beide gegenseitig misstrauische Dienste an verschiedenen Ports desselben Hosts ausführen und Cookies zum Speichern sicherheitsrelevanter Informationen verwenden.
Gemäß RFC2965 3.3.1 (dem möglicherweise Browser folgen oder nicht) werden Cookies möglicherweise an keinen Port gesendet , sofern der Port nicht explizit über den portParameter des Set-CookieHeaders angegeben wird.
Im Browser-Sicherheitshandbuch von Google heißt es: Standardmäßig ist der Cookie-Bereich auf alle URLs des aktuellen Hostnamens beschränkt - und nicht an Port- oder Protokollinformationen gebunden. und einige Zeilen später Es gibt keine Möglichkeit, Cookies nur auf einen einzigen DNS-Namen zu beschränken, [...] ebenso wie es keine Möglichkeit gibt, sie auf einen bestimmten Port zu beschränken. (Auch im Auge behalten, dass der IE nicht Faktor Portnummern in die Same Origin Policy überhaupt .)
Es scheint also nicht sicher zu sein, sich hier auf ein genau definiertes Verhalten zu verlassen.
Dies ist eine sehr alte Frage, aber ich dachte, ich würde eine Problemumgehung hinzufügen, die ich verwendet habe.
Auf meinem Laptop laufen zwei Dienste (einer auf Port 3000 und der andere auf 4000). Wenn ich zwischen ( http://localhost:3000und http://localhost:4000) wechseln würde, würde Chrome dasselbe Cookie übergeben, jeder Dienst würde das Cookie nicht verstehen und ein neues generieren.
Wenn ich auf http://localhost:3000und zugegriffen habe http://127.0.0.1:4000, ist das Problem behoben, da Chrome ein Cookie für localhost und eines für 127.0.0.1 gespeichert hat.
Auch hier mag es niemanden interessieren, aber es war einfach und hilfreich für meine Situation.
localhostnicht mit geteilt werden 127.0.0.1und umgekehrt. Cookies auf demselben Host / derselben Domain können jedoch unabhängig vom Port gemeinsam genutzt werden.
Dies ist eine große Grauzone in der Cookie-SOP (Same Origin Policy).
Theoretisch können Sie die Portnummer in der Domäne angeben, und das Cookie wird nicht freigegeben. In der Praxis funktioniert dies nicht mit mehreren Browsern, und Sie werden auf andere Probleme stoßen. Dies ist also nur möglich, wenn Ihre Websites nicht für die breite Öffentlichkeit bestimmt sind und Sie steuern können, welche Browser verwendet werden sollen.
Der bessere Ansatz besteht darin, zwei Domainnamen für dieselbe IP zu erhalten und sich bei Cookies nicht auf Portnummern zu verlassen.
Eine alternative Möglichkeit, das Problem zu umgehen, besteht darin, den Namen des Sitzungscookies portbezogen zu machen. Zum Beispiel:
Ihr Code kann auf die Webserverkonfiguration zugreifen, um herauszufinden, welchen Port Ihr Server verwendet, und das Cookie entsprechend benennen.
Beachten Sie, dass Ihre Anwendung beide Cookies erhält und Sie das Cookie anfordern müssen, das Ihrem Port entspricht.
Es ist nicht erforderlich, die genaue Portnummer im Cookie-Namen zu haben, dies ist jedoch bequemer.
Im Allgemeinen kann der Cookie-Name jeden anderen Parameter codieren, der für die von Ihnen verwendete Serverinstanz spezifisch ist, sodass er durch den richtigen Kontext dekodiert werden kann.
Ich hatte ein ähnliches Problem beim Ausführen (und beim Debuggen) von zwei verschiedenen Django-Anwendungen auf demselben Computer.
Ich habe sie mit folgenden Befehlen ausgeführt:
./manage.py runserver 8000
./manage.py runserver 8001
Wenn ich mich beim ersten und dann beim zweiten angemeldet habe, wurde ich immer beim ersten und umgekehrt abgemeldet.
Ich habe dies auf meinen / etc / hosts hinzugefügt
127.0.0.1 app1
127.0.0.1 app2
Dann habe ich die beiden Apps mit folgenden Befehlen gestartet:
./manage.py runserver app1:8000
./manage.py runserver app2:8001
Problem gelöst :)
127.0.0.1:8000für eine, localhost:8000für eine Sekunde und möglicherweise ::1:8000(vielleicht [::1]:8080) für eine dritte verwenden, ohne jemals die Hosts-Datei berühren zu müssen.
::1 app1 app2 app3 app4 app5 appN
Es ist optional.
Der Port kann angegeben werden, sodass Cookies portspezifisch sein können. Es ist nicht notwendig, der Webserver / die Anwendung muss sich darum kümmern.
Quelle: Deutscher Wikipedia-Artikel , RFC2109 , Kapitel 4.3.1
PortParameter imSet-CookieHeader (da ihn in der Praxis fast niemand verwendet hat) und macht deutlich, dass Cookies auf demselben Host NICHT mehr durch Ports unterscheidbar sind.