2009-10-23 12 views

Odpowiedz

206

Obecna specyfikacja plików cookie to RFC 6265, która zastępuje RFC 2109 i RFC 2965 (oba dokumenty RFC są teraz oznaczone jako "Historyczne") i formalizuje składnię dla rzeczywistych zastosowań plików cookie. Wyraźnie stwierdza:

  1. Wprowadzenie

...

Ze względów historycznych, ciasteczka zawierają szereg zabezpieczeń i prywatności nieszczęśliwości. Na przykład, serwer może wskazać, że dany plik cookie jest przeznaczony do "bezpiecznych" połączeń, ale atrybut Bezpieczny nie zapewnia integralności w obecności aktywnego napastnika sieciowego. Podobnie pliki cookie dla danego hosta są udostępniane wszystkim portom na tym hoście, mimo że zwykłe zasady "tego samego pochodzenia" używane przez przeglądarki internetowe izolują zawartość pobieraną przez różne porty.

A także:

8,5. Słaba poufność

Pliki cookie nie zapewniają izolacji przez port. Jeśli plik cookie jest odczytywalny przez usługę działającą na jednym porcie, plik cookie jest również odczytywany przez usługę działającą na innym porcie tego samego serwera. Jeśli plik cookie jest zapisywalny przez usługę na jednym porcie, plik cookie jest zapisywalny również przez usługę działającą na innym porcie tego samego serwera. Z tego powodu serwery NIE MOGĄ zarówno uruchamiać wzajemnie nieufnych usług na różnych portach tego samego hosta, jak i używać plików cookie do przechowywania informacji poufnych.

1

To opcjonalne.

Port może być określony, więc pliki cookie mogą być specyficzne dla portu. Nie jest konieczne, serwer internetowy/aplikacja musi się tym zająć.

Źródło: German Wikipedia article, RFC2109 rozdział 4.3.1

+2

[brzmi jak to jest bardziej skomplikowane niż w rzeczywistości.] (http://stackoverflow.com/questions/1612177/are-http-cookies-port-specific/4212964#4212964) – bzlm

18

Jest to duża szara strefa w cookies SOP (sama polityka Origin).

Teoretycznie można podać numer portu w domenie, a plik cookie nie zostanie udostępniony. W praktyce nie działa to w przypadku kilku przeglądarek, a pojawią się inne problemy. Jest to możliwe tylko wtedy, gdy twoje witryny nie są dostępne dla ogółu społeczeństwa i możesz kontrolować, jakich przeglądarek użyć.

Lepszym rozwiązaniem jest uzyskanie dwóch nazw domen dla tego samego adresu IP i nie poleganie na numerach portów dla plików cookie.

+7

To nie jest szare obszar już. [RFC 6265] (http://tools.ietf.org/html/rfc6265), który jest obecnie standardem plików cookie, eliminuje wszelkie zamieszanie, po prostu eliminując możliwość oddzielania plików cookie na tym samym hoście za pomocą różnych portów. –

112

Według RFC2965 3.3.1 (który może lub nie może być następnie przeglądarek), chyba że port jest wyraźnie określony przez parametr nagłówka Set-Cookieport, ciasteczka mogą lub nie mogą być wysyłane do dowolnego portu.

Domyślnie Google : , zakres plików cookie jest ograniczony do wszystkich adresów URL na bieżącej nazwie hosta - i nie jest powiązany z informacjami o porcie lub protokole. i niektóre linie później Nie ma możliwości ograniczenia plików cookie do pojedynczej nazwy DNS [...] podobnie, nie ma możliwości ograniczenia ich do określonego portu. (Również należy pamiętać, że IE nie uwzględnia numery portów do swojej polityki tego samego pochodzenia wcale.)

Więc nie wydaje się być bezpieczne polegać na dobrze zdefiniowanych zachowań tutaj.

+51

[RFC 6265] (http://tools.ietf.org/html/rfc6265), który zastępuje RFC 2965, eliminuje parametr 'Port' w nagłówku' Set-Cookie' (ponieważ prawie nikt nie używał go w praktyce) i wyraźnie zaznacza, że ​​pliki cookie na tym samym hoście nie są już rozpoznawalne przez porty. –

+4

IE 9 nie odeśle ciasteczka z powrotem na kolejne żądania, jeśli domena ma w nim port – axk

+2

Czy istnieje jakaś przeglądarka, która wciąż rozważa port w swoich SOP ciasteczek? – Bertuz

14

Alternatywnym sposobem na obejście problemu jest podanie nazwy sesji cookie jako powiązanej z portem. Na przykład:

  • mysession8080 serwera działa na porcie 8080
  • mysession8000 na serwer działa na porcie 8000

Twój kod może uzyskać dostęp do konfiguracji serwera WWW, aby dowiedzieć się, który port twój serwer używa i odpowiednio nazwę ciasteczka.

Należy pamiętać, że Twoja aplikacja otrzyma oba pliki cookie i będzie wymagać tego, który odpowiada Twojemu portowi.

Nie ma potrzeby podawania dokładnego numeru portu w nazwie pliku cookie, ale jest to wygodniejsze.

Ogólnie nazwa pliku cookie może kodować dowolny inny parametr właściwy dla używanej instancji serwera, dzięki czemu może zostać zdekodowany w odpowiednim kontekście.

9

W IE 8 pliki cookie (zweryfikowane tylko w stosunku do localhost) są udostępniane między portami. W FF 10 nie są.

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

42

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 (jeden na porcie 3000, a drugi na 4000). Gdy przechodzę pomiędzy (http://localhost:3000 i http://localhost:4000), Chrome będzie przekazywał ten sam plik cookie, a każda usługa nie zrozumie pliku cookie i nie wygeneruje nowego.

Znalazłem, że jeśli uzyskałem dostęp do http://localhost:3000 i http://127.0.0.1:4000, problem zniknął, ponieważ Chrome zachował plik cookie dla localhost i jeden dla 127.0.0.1.

Znowu nikt nie może się tym przejmować, ale to było łatwe i pomocne w mojej sytuacji.

+0

Tak, ponieważ pliki cookie są powiązane z nazwami hosta/domeny, więc plik cookie na 'localhost' nie może być udostępniony przez' 127.0.0.1' i na odwrót. Ale pliki cookie na tym samym hoście/domenie, niezależnie od portu, są udostępniane. –

+0

To prawdopodobnie działa tylko w Chrome, ponieważ większość innych przeglądarek nie wysyła plików cookie do "localhost" (= ciąg bez dwóch kropek). – Max

+3

Oczywiście, że tak. Ja (i prawdopodobnie milion innych programistów) używam localhost do testowania przez cały czas. O ile dodany port nie robi różnicy: http: // localhost: 8080/ –

2

Wystąpił podobny problem z uruchomieniem (i próbą debugowania) dwóch różnych aplikacji Django na tym samym komputerze.

biegałam je z tych poleceń:

./manage.py runserver 8000 
./manage.py runserver 8001 

Kiedy zrobiłem logowanie w pierwszym, a następnie w drugim, ale ja zawsze wylogować się pierwszy i na odwrót.

dodałem to na moich /etc/hosts

127.0.0.1 app1 
127.0.0.1 app2 

Potem zacząłem dwie aplikacje z tych poleceń:

./manage.py runserver app1:8000 
./manage.py runserver app2:8001 

problem rozwiązany :)

+3

możesz prawdopodobnie używać '127.0.0.1: 8000' dla jednego,' localhost: 8000' na sekundę i być może ':: 1: 8000' (może' [:: 1]: 8080') na jedną trzecią, nigdy wcześniej. konieczności dotknięcia pliku hosts. – Travis

+0

możesz umieścić go w jednym wierszu: '' ':: 1 app1 app2 app3 app4 app5 appN''' – aeroson

Powiązane problemy