Odpowiedzi:
Obecna specyfikacja plików cookie to RFC 6265 , która zastępuje RFC 2109 i RFC 2965 (oba RFC są teraz oznaczone jako „Historyczne”) i formalizuje składnię rzeczywistych zastosowań plików cookie. Wyraźnie stwierdza:
- Wprowadzenie
...
Ze względów historycznych pliki cookie zawierają wiele informacji dotyczących bezpieczeństwa i prywatności. Na przykład serwer może wskazywać, że dany plik cookie jest przeznaczony do „bezpiecznych” połączeń, ale atrybut Secure nie zapewnia integralności w obecności aktywnego atakującego w sieci. Podobnie pliki cookie dla danego hosta są współużytkowane przez wszystkie porty na tym hoście, mimo że zwykłe „zasady tego samego pochodzenia” używane przez przeglądarki internetowe izolują treści pobierane przez różne porty.
I również:
8.5 Słaba poufność
Pliki cookie nie zapewniają izolacji według portów . Jeśli plik cookie jest możliwy do odczytania przez usługę działającą na jednym porcie, plik cookie może być również odczytany przez usługę uruchomioną na innym porcie tego samego serwera. Jeśli plik cookie jest zapisywalny przez usługę na jednym porcie, plik cookie jest również zapisywalny przez usługę uruchomioną na innym porcie tego samego serwera. Z tego powodu serwery NIE POWINNY uruchamiać wzajemnie nieufnych usług na różnych portach tego samego hosta i używać plików cookie do przechowywania poufnych informacji.
Zgodnie z RFC2965 3.3.1 (po których mogą lub nie następuje przeglądarka), chyba że port jest wyraźnie określony za pomocą portparametru Set-Cookienagłówka, pliki cookie mogą, ale nie muszą być wysyłane do dowolnego portu.
W Podręczniku bezpieczeństwa przeglądarki Google napisano: domyślnie zakres plików cookie jest ograniczony do wszystkich adresów URL bieżącej nazwy hosta - i nie jest powiązany z informacjami o porcie ani protokole. a niektóre wiersze później Nie ma możliwości ograniczenia plików cookie tylko do jednej nazwy DNS [...] podobnie, nie ma możliwości ograniczenia ich do określonego portu. (Również należy pamiętać, że IE robi numery portów nie wpływających na jego polityki tego samego pochodzenia w ogóle ).
Nie wydaje się zatem bezpieczne poleganie na żadnym dobrze zdefiniowanym zachowaniu.
To naprawdę stare pytanie, ale pomyślałem, że dodam obejście, którego użyłem.
Mam dwie usługi uruchomione na moim laptopie (jedna na porcie 3000, a druga na 4000). Gdy przeskakiwałem między ( http://localhost:3000i http://localhost:4000), Chrome przekazywałby ten sam plik cookie, każda usługa nie rozumiałaby pliku cookie i generowała nowy.
Odkryłem, że jeśli uzyskam dostęp http://localhost:3000 i http://127.0.0.1:4000problem zniknął, ponieważ Chrome zachował plik cookie dla hosta lokalnego i jeden dla 127.0.0.1.
Znowu nikomu to nie obchodzi, ale było to łatwe i pomocne w mojej sytuacji.
localhostnie można udostępniać 127.0.0.1i odwrotnie. Ale pliki cookie na tym samym hoście / domenie, niezależnie od portu, można udostępniać.
Jest to duża szara strefa w SPO plików cookie (ta sama zasada pochodzenia).
Teoretycznie możesz podać numer portu w domenie, a plik cookie nie zostanie udostępniony. W praktyce nie działa to z kilkoma przeglądarkami i napotkasz inne problemy. Jest to możliwe tylko wtedy, gdy witryny nie są przeznaczone dla ogółu społeczeństwa i można kontrolować, z jakich przeglądarek korzystać.
Lepszym rozwiązaniem jest uzyskanie 2 nazw domen dla tego samego adresu IP i nie poleganie na numerach portów dla plików cookie.
Alternatywnym sposobem obejścia problemu jest powiązanie nazwy pliku cookie sesji z portem. Na przykład:
Twój kod może uzyskać dostęp do konfiguracji serwera WWW, aby dowiedzieć się, którego portu używa Twój serwer i odpowiednio nazwać plik cookie.
Pamiętaj, że Twoja aplikacja otrzyma oba pliki cookie i musisz poprosić o ten, który odpowiada Twojemu portowi.
Nie trzeba podawać dokładnego numeru portu w nazwie pliku cookie, ale jest to wygodniejsze.
Zasadniczo nazwa pliku cookie może kodować dowolny inny parametr specyficzny dla używanej instancji serwera, dzięki czemu może zostać zdekodowany we właściwym kontekście.
Wystąpił podobny problem z uruchomieniem (i próbą debugowania) dwóch różnych aplikacji Django na tym samym komputerze.
Uruchomiłem je za pomocą następujących poleceń:
./manage.py runserver 8000
./manage.py runserver 8001
Kiedy logowałem się w pierwszym, a potem w drugim zawsze wylogowywałem się z pierwszego i viceversa.
Dodałem to na moich / etc / hosts
127.0.0.1 app1
127.0.0.1 app2
Następnie uruchomiłem dwie aplikacje za pomocą następujących poleceń:
./manage.py runserver app1:8000
./manage.py runserver app2:8001
Problem rozwiązany :)
127.0.0.1:8000jednego, localhost:8000drugiego, a być ::1:8000może [::1]:8080trzeciego, nawet bez dotykania pliku hosts.
::1 app1 app2 app3 app4 app5 appN
To jest opcjonalne.
Port można określić, aby pliki cookie mogły być specyficzne dla portu. Nie jest to konieczne, serwer / aplikacja internetowa musi się tym zająć.
Źródło: niemiecki artykuł w Wikipedii , RFC2109 , rozdział 4.3.1
Portparametr wSet-Cookienagłówku (ponieważ prawie nikt tak naprawdę go nie używał w praktyce) i wyraźnie mówi, że pliki cookie na tym samym hoście NIE są już odróżnialne przez porty.