Jak działają domeny plików cookie przeglądarki?

Z powodu dziwnych problemów z plikami cookie domeny / subdomeny, które dostaję, chciałbym wiedzieć, w jaki sposób przeglądarki obsługują pliki cookie. Jeśli robią to na różne sposoby, dobrze byłoby poznać różnice.

Innymi słowy - gdy przeglądarka otrzyma plik cookie, plik cookie MUSI mieć domenę i ścieżkę do niej dołączoną. Lub nie, w którym to przypadku przeglądarka prawdopodobnie zastępuje niektóre ustawienia domyślne. Pytanie 1: czym one są?

Później, gdy przeglądarka ma zamiar wysłać żądanie, sprawdza swoje pliki cookie i odfiltrowuje te, które powinien wysłać dla tego żądania. Robi to, dopasowując je do ścieżki żądań i domeny. Pytanie 2: jakie są reguły dopasowania?

Pytam o to, ponieważ jestem zainteresowany niektórymi przypadkowymi przypadkami. Lubić:

• Czy .example.combędzie dostępny plik cookie www.example.com?
• Czy .example.combędzie dostępny plik cookie example.com?
• Czy example.combędzie dostępny plik cookie www.example.com?
• Czy example.combędzie dostępny plik cookie anotherexample.com?
• Będzie www.example.com będzie można ustawić ciasteczko example.com?
• Będzie www.example.commógł ustawić ciasteczko dlawww2.example.com?
• Będzie www.example.commógł ustawić ciasteczko dla.com?
• Itp.

Dodano 2:

Czy ktoś mógłby zasugerować, jak ustawić ciasteczko, aby:

• Można to ustawić za pomocą www.example.comlub example.com;
• Jest dostępny zarówno dla, jak www.example.comi dla example.com.

Chociaż istnieje RFC 2965 ( Set-Cookie2, który już zdezaktualizował RFC 2109 ), który powinien definiować plik cookie, większość przeglądarek nie obsługuje go w pełni, ale po prostu jest zgodna z oryginalną specyfikacją Netscape .

Istnieje różnica między wartością atrybutu Domain a domeną efektywną: pierwsza jest pobierana z Set-Cookiepola nagłówka, a druga jest interpretacją tej wartości atrybutu. Zgodnie z RFC 2965 powinny mieć zastosowanie następujące zasady:

• Jeśli pole nagłówka Set-Cookie nie ma domeny atrybutu , domeną efektywną jest domena żądania.
• Jeśli istnieje atrybut Domain , jego wartość zostanie wykorzystana jako domena efektywna (jeśli wartość nie zaczyna się od ., zostanie dodana przez klienta).

Mając efektywną domenę, musi być również dopasowana do bieżącej domeny, o którą ma być ustawiony; w przeciwnym razie plik cookie zostanie zmieniony. Ta sama zasada dotyczy wyboru plików cookie, które mają zostać wysłane w żądaniu.

Wykorzystując tę ​​wiedzę w swoich pytaniach, powinny mieć zastosowanie następujące zasady:

• Pliki cookie Domain=.example.com będą dostępne na stronie www.example.com
• Pliki cookie z Domain=.example.com będą dostępne na przykład.com
• Pliki cookie Domain=example.comzostaną przekonwertowane na, .example.comdzięki czemu będą również dostępne na stronie www.example.com
• Cookie ze Domain=example.combędzie nie być dostępny dla anotherexample.com
• www.example.com będzie mógł ustawić ciasteczko na przykład.com
• www.example.com będzie nie być w stanie ustawić ciasteczko dla www2.example.com
• www.example.com będzie nie być w stanie ustawić ciasteczko dla .com

Aby ustawić i odczytać plik cookie dla / przez www.example.com i example.com , ustaw odpowiednio dla .www.example.comi .example.com. Ale pierwsza ( .www.example.com) będzie dostępna tylko dla innych domen poniżej tej domeny (np. Foo.www.example.com lub bar.www.example.com ), do których .example.commożna również uzyskać dostęp z dowolnej innej domeny poniżej example.com (np . Foo. example.com lub bar.example.com ).

Poprzednie odpowiedzi są trochę nieaktualne.

RFC 6265 został opublikowany w 2011 roku na podstawie konsensusu przeglądarki w tym czasie. Od tego czasu wystąpiły pewne komplikacje z publicznymi domenami sufiksów. Napisałem artykuł wyjaśniający obecną sytuację - http://bayou.io/draft/cookie.domain.html

Podsumowując, należy przestrzegać zasad dotyczących domeny plików cookie:

• Domeny pochodzenie pliku cookie jest domeną żądanie pochodzące.

• Jeśli domeną źródłową jest adres IP, atrybut domeny pliku cookie nie może być ustawiony.

• Jeśli atrybut domeny pliku cookie nie jest ustawiony, plik cookie ma zastosowanie tylko do jego domeny pochodzenia.

• Jeśli ustawiony jest atrybut domeny pliku cookie,

  • plik cookie ma zastosowanie do tej domeny i wszystkich jej subdomen;
  • domena pliku cookie musi być taka sama lub nadrzędna w stosunku do domeny pochodzenia
  • domena pliku cookie nie może być TLD, sufiksem publicznym ani rodzicem sufiksu publicznego.

Można wywnioskować, że plik cookie ma zawsze zastosowanie do jego domeny pochodzenia.

Domena plików cookie nie powinna mieć wiodącej kropki, jak w .foo.comzwykłym użyciufoo.com

Jako przykład,

• x.y.z.comMożna ustawić domenę cookie siebie lub rodziców - x.y.z.com, y.z.com, z.com. Ale nie com, co jest publicznym przyrostkiem.
• cookie z domeny = y.z.comdotyczy y.z.com, x.y.z.com, a.x.y.z.comitd.

Przykłady przyrostków publicznych - com, edu, uk, co.uk, blogspot.com,compute.amazonaws.com

Aby uzyskać obszerne omówienie, przejrzyj zawartość RFC2965 . Oczywiście nie musi to oznaczać, że wszystkie przeglądarki zachowują się dokładnie tak samo.

Jednak ogólnie rzecz biorąc, reguła domyślnej ścieżki, jeśli nie jest podana w pliku cookie, jest ścieżką w adresie URL, z którego przyszedł nagłówek pliku cookie. Podobnie domyślna domena to pełna nazwa hosta w adresie URL, z którego przyszedł plik cookie Set.

Reguły dopasowania dla domeny wymagają, aby Domena plików cookie pasowała do hosta, do którego wysyłane jest żądanie. Plik cookie może określać szersze dopasowanie do domeny poprzez włączenie *. w atrybucie domeny Set-Cookie (w tym obszarze przeglądarki mogą się różnić). Dopasowanie ścieżki (zakładając, że domena pasuje) jest prostą sprawą, że żądana ścieżka musi znajdować się w ścieżce określonej w pliku cookie. Zazwyczaj sesyjne pliki cookie są ustawiane za pomocą path = / lub path = / applicationName /, więc cookie jest dostępne dla wszystkich żądań w aplikacji.

• Czy plik cookie dla .example.com będzie dostępny dla www.example.com? tak
• Czy plik cookie dla .example.com będzie dostępny dla example.com? Nie wiem
• Czy plik cookie na przykład example.com będzie dostępny dla www.example.com? Nie powinien, ale ... *
• Czy plik cookie na przykład.com będzie dostępny dla anotherexample.com? Nie
• Czy www.example.com będzie mógł ustawić ciasteczko na przykład.com? tak
• Czy www.example.com będzie mógł ustawić ciasteczko dla www2.example.com? Nie (z wyjątkiem poprzez .example.com)
• Czy www.example.com będzie mógł ustawić ciasteczko dla .com? Nie (nie można ustawić ciasteczka tak wysoko w przestrzeni nazw, ani nie można ustawić takiego dla czegoś takiego jak .co.uk) .

*Nie mogę teraz tego przetestować, ale mam wrażenie, że przynajmniej IE7 / 6 potraktowałoby ścieżkę example.comtak, jakby to było .example.com.

Ostatnim (dokładnie trzecim) RFC dla tego problemu jest RFC-6265 (Przestarzałe RFC-2965, które z kolei przestarza RFC-2109).

Zgodnie z nim, jeśli serwer pominie atrybut Domain, agent użytkownika zwróci plik cookie tylko do serwera źródłowego (serwera, na którym rezyduje dany zasób). Ale ostrzega również, że niektóre istniejące programy klienckie traktują nieobecny atrybut Domain tak, jakby atrybut Domain był obecny i zawierał bieżącą nazwę hosta (na przykład, jeśli example.com zwraca nagłówek Set-Cookie bez atrybutu Domain, te agenty użytkownika będą również błędnie wyślij plik cookie na www.example.com).

Po określeniu atrybutu Domain będzie on traktowany jako pełna nazwa domeny (jeśli w atrybucie jest wiodąca kropka, zostanie zignorowany). Serwer powinien pasować do domeny określonej w atrybucie (mieć dokładnie taką samą nazwę domeny lub być jej poddomeną), aby uzyskać ten plik cookie. Dokładniej to określono tutaj .

Na przykład:

• atrybut cookie Domain=.example.comjest równoważnyDomain=example.com
• pliki cookie z takimi atrybutami domeny będą dostępne na przykład.com i www.example.com
• pliki cookie z takimi atrybutami domeny nie będą dostępne dla witryny inny-przyklad.com
• określenie atrybutu pliku cookie, takiego jak Domain=www.example.comzamknie drogę dla www4.example.com

PS: przecinek końcowy w atrybucie domeny spowoduje, że agent użytkownika zignoruje atrybut = (

Testowałem wszystkie przypadki w najnowszym Chrome, Firefox, Safari w 2019 roku.

Odpowiedź na dodane:

• Czy plik cookie dla .example.com będzie dostępny dla www.example.com? TAK
• Czy plik cookie dla .example.com będzie dostępny dla example.com? TAK
• Czy plik cookie na przykład example.com będzie dostępny dla www.example.com? NIE , Domena bez symbolu wieloznacznego pasuje tylko do siebie.
• Czy plik cookie na przykład.com będzie dostępny dla anotherexample.com? NIE
• Czy www.example.com będzie mógł ustawić ciasteczko na przykład.com? NIE , będzie mógł ustawić plik cookie dla „.example.com”, ale nie dla „example.com”.
• Czy www.example.com będzie mógł ustawić ciasteczko dla www2.example.com? NO . Ale może ustawić plik cookie dla .example.com, do którego www2.example.com może uzyskać dostęp.
• Czy www.example.com będzie mógł ustawić ciasteczko dla .com? NIE

Wiadomo, że RFC nie odzwierciedlają rzeczywistości.

Lepiej sprawdź wersję roboczą ietf-httpstate-cookie , praca w toku.

Istnieją zasady, które określają, czy przeglądarka zaakceptuje nagłówek odpowiedzi nagłówka Set (zapisywanie plików cookie po stronie serwera), nieco inne reguły / interpretacje dla zestawu plików cookie przy użyciu Javascript (nie testowałem VBScript).

Następnie istnieją reguły określające, czy przeglądarka wyśle ​​plik cookie wraz z żądaniem strony.

Istnieją różnice między głównymi silnikami przeglądarki, w jaki sposób obsługiwane są dopasowania domen i jak interpretowane są parametry w wartościach ścieżek. Niektóre dowody empiryczne można znaleźć w artykule Jak różne przeglądarki traktują pliki cookie inaczej

Zaskoczyło mnie przeczytanie sekcji 3.3.2 na temat odrzucania plików cookie:

http://tools.ietf.org/html/rfc2965

Oznacza to, że przeglądarka powinna odrzucić plik cookie od xyzcom z domeną .z.com, ponieważ „xy” zawiera kropkę. Tak więc, chyba że źle interpretuję RFC i / lub powyższe pytania, mogą zostać dodane pytania:

Czy plik cookie dla .example.com będzie dostępny dla www.yyy.example.com? Nie.

Czy plik cookie ustawiony przez serwer pochodzenia www.yyy.example.com z domeną .example.com ma wartość przesłaną przez agenta użytkownika do xxx.example.com? Nie.

Czywww.example.com będzie można ustawić ciasteczko .com?

Nie, ale example.com.frmoże być w stanie ustawić plik cookie example2.com.fr. Firefox chroni przed tym, utrzymując listę TLD: http://securitylabs.websense.com/content/Blogs/3108.aspx

Najwyraźniej Internet Explorer nie zezwala domenom dwuliterowym na ustawianie plików cookie, co, jak sądzę, wyjaśnia, dlaczego o2.iepo prostu przekierowuje o2online.ie. Często się nad tym zastanawiałem.