Czy pliki cookie HTTP są specyficzne dla portu?

Mam dwie usługi HTTP działające na jednym komputerze. Chcę tylko wiedzieć, czy udostępniają swoje pliki cookie, czy przeglądarka rozróżnia dwa gniazda serwera.

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:

1. 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.

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:

• mysession8080 dla serwera działającego na porcie 8080
• mysession8000 dla serwera działającego na porcie 8000

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.

W IE 8 pliki cookie (zweryfikowane tylko w przypadku hosta lokalnego) są udostępniane między portami. W FF 10 nie są.

Opublikowałem tę odpowiedź, aby czytelnicy mieli co najmniej jedną konkretną opcję testowania każdego scenariusza.

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 :)

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