Czy pliki cookie HTTP są specyficzne dla portu?

355

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.

guerda
źródło

Odpowiedzi:

329

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.

Remy Lebeau
źródło
129

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.

Tgr
źródło
75
RFC 6265 , który zastępuje RFC 2965, eliminuje Portparametr w Set-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.
Remy Lebeau
5
IE 9 nawet nie odeśle ciasteczka z powrotem przy kolejnych żądaniach, jeśli domena ma w nim port
axk
3
Czy jest jakaś przeglądarka, która nadal rozważa port w SOP swoich plików cookie?
Bertuz
5
Chrome nawet nie ustawi pliku cookie, jeśli ma domenę z portem.
Pim Heijden,
76

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.

Poklepać
źródło
1
Tak, ponieważ pliki cookie są powiązane z nazwami hosta / domeny, więc pliku cookie 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ć.
Remy Lebeau
3
Oczywiście, że tak. Ja (i prawdopodobnie milion innych programistów) używam localhost do testowania przez cały czas. Chyba że dodany port robi różnicę: localhost: 8080
David Balažic
53
Możesz także użyć 127.0.0.1, 127.0.0.2, 127.0.0.3 itd. ... wszystkie one oznaczają localhost.
David Balažic
3
Nie mogę głosować za tym, ponieważ nie odpowiada na pytanie, ale to świetna wskazówka, dzięki!
Martin T.
2
Jeśli chcesz edytować plik hosts (/ etc / hosts na Uniksie), możesz mieć tyle znaczących nazw, ile chcesz dla localhost.
Silas S. Brown
20

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.

ZZ Coder
źródło
9
To już nie jest szara strefa. RFC 6265 , który jest obecnym standardem plików cookie, eliminuje wszelkie niejasności, po prostu eliminując możliwość oddzielania plików cookie na tym samym hoście przy użyciu różnych portów.
Remy Lebeau
18

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.

Manolis M. Tsangaris
źródło
9

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.

Jeb
źródło
4

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

Andrea Grandi
źródło
4
prawdopodobnie możesz użyć 127.0.0.1:8000jednego, localhost:8000drugiego, a być ::1:8000może [::1]:8080trzeciego, nawet bez dotykania pliku hosts.
Travis Watson,
1
możesz umieścić go w jednym wierszu:::1 app1 app2 app3 app4 app5 appN
aeroson