Udostępniaj pliki cookie między subdomeną i domeną

Mam dwa pytania. Rozumiem, że jeśli podam domenę jako .mydomain.com(z kropką wiodącą) w pliku cookie, wszystkie subdomeny mogą udostępniać plik cookie.

Czy można subdomain.mydomain.comuzyskać dostęp do pliku cookie utworzonego w mydomain.com(bez wwwpoddomeny)?

Czy mydomain.com(bez wwwpoddomeny) może uzyskać dostęp do pliku cookie, jeśli został utworzony subdomain.mydomain.com?

Dwie domeny mydomain.comi subdomain.mydomain.commogą udostępniać pliki cookie tylko wtedy, gdy domena jest wyraźnie wymieniona w Set-Cookienagłówku. W przeciwnym razie zakres pliku cookie jest ograniczony do hosta żądań. (Jest to określane jako „plik cookie tylko dla hosta”. Zobacz Co to jest plik cookie tylko dla hosta? )

Na przykład, jeśli wysłałeś następujący nagłówek subdomain.mydomain.com, plik cookie nie zostanie wysłany z żądaniami do mydomain.com:

Set-Cookie: name=value

Jeśli jednak użyjesz następujących opcji, będzie to możliwe w obu domenach:

Set-Cookie: name=value; domain=mydomain.com

Ten plik cookie zostanie wysłany dla dowolnej subdomeny mydomain.com, w tym takich jak zagnieżdżone subdomeny subsub.subdomain.mydomain.com.

W RFC 2109 domena bez kropki wiodącej oznaczała, że ​​nie można jej używać w subdomenach, a tylko kropka wiodąca ( .mydomain.com) pozwala na użycie jej w wielu subdomenach (ale nie w domenie najwyższego poziomu, więc zapytano niemożliwe w starszej specyfikacji).

Jednak wszystkie nowoczesne przeglądarki są zgodne z nowszą specyfikacją RFC 6265 i zignorują każdą kropkę wiodącą, co oznacza, że ​​możesz używać plików cookie w subdomenach, a także w domenie najwyższego poziomu.

Podsumowując, jeśli ustawisz plik cookie taki jak w drugim przykładzie powyżej mydomain.com, będzie on dostępny przez subdomain.mydomain.comi na odwrót. Można to również wykorzystać do zezwalania sub1.mydomain.comi sub2.mydomain.comudostępniania plików cookie.

Zobacz też:

• www vs no-www i ciasteczka
• skrypt testowy plików cookie, aby go wypróbować

Nie jestem pewien, czy odpowiedź @cmbuckley pokazuje pełny obraz. To co czytam to:

O ile atrybuty pliku cookie nie wskazują inaczej, plik cookie jest zwracany tylko do serwera źródłowego (a nie, na przykład, do dowolnych subdomen) i wygasa z końcem bieżącej sesji (zgodnie z definicją klienta użytkownika). Aplikacje klienckie ignorują nierozpoznany plik cookie.

RFC 6265

Również

8.6.  Weak Integrity

   Cookies do not provide integrity guarantees for sibling domains (and
   their subdomains).  For example, consider foo.example.com and
   bar.example.com.  The foo.example.com server can set a cookie with a
   Domain attribute of "example.com" (possibly overwriting an existing
   "example.com" cookie set by bar.example.com), and the user agent will
   include that cookie in HTTP requests to bar.example.com.  In the
   worst case, bar.example.com will be unable to distinguish this cookie
   from a cookie it set itself.  The foo.example.com server might be
   able to leverage this ability to mount an attack against
   bar.example.com.

Dla mnie oznacza to, że możesz chronić pliki cookie przed odczytaniem przez subdomenę / domenę, ale nie możesz zapobiec zapisywaniu plików cookie w innych domenach. Aby ktoś mógł przepisać pliki cookie witryny, kontrolując inną subdomenę odwiedzaną przez tę samą przeglądarkę. Co może nie być dużym problemem.

Niesamowita strona testowa ciasteczek dostarczona przez @cmbuckley / dla tych, którzy przegapili ją w swojej odpowiedzi, takiej jak ja; warte przewijania w górę i w górę /:

• http://scripts.cmbuckley.co.uk/cookies.php

Oto przykład z wykorzystaniem interfejsu API cookie DOM ( https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie ), abyśmy sami mogli zobaczyć zachowanie.

Jeśli wykonamy następujący JavaScript:

document.cookie = "klucz = wartość"

Wygląda to tak samo jak wykonywanie:

document.cookie = "klucz = wartość; domena = mojadomena.com"

Klucz cookie staje się dostępny (tylko) w domenie mojadomena.com .

Teraz, jeśli wykonasz następujący JavaScript w mydomain.com:

document.cookie = "klucz = wartość; domena = .moja_domena.com"

Klucz cookie staje się dostępny dla mydomain.com oraz subdomain.mydomain.com .

Na koniec, jeśli spróbujesz wykonać następujące czynności na subdomain.mydomain.com:

document.cookie = "klucz = wartość; domena = .moja_domena.com"

Czy klucz cookie jest dostępny dla subdomain.mydomain.com ? Byłem trochę zaskoczony, że jest to dozwolone; Zakładałem, że naruszenie zasad bezpieczeństwa dla subdomeny może umożliwić ustawienie pliku cookie w domenie nadrzędnej.

Pamiętaj, że możesz ustawić plik cookie z subdomeny w domenie.

(wysłany w odpowiedzi na żądanie subdomain.mydomain.com)

Set-Cookie: name=value; Domain=mydomain.com // GOOD

Ale NIE MOŻESZ ustawić pliku cookie z domeny w subdomenie.

(wysłany w odpowiedzi na żądanie mydomain.com)

Set-Cookie: name=value; Domain=subdomain.mydomain.com // Browser rejects cookie

DLACZEGO ?

Zgodnie ze specyfikacją RFC 6265 sekcja 5.3.6 Model pamięci

Jeśli kanoniczny host żądań nie zgadza się z atrybutem domeny: Całkowicie zignoruj ​​plik cookie i przerwij te kroki.

i RFC 6265 sekcja 5.1.3 Dopasowanie domen

Dopasowanie domeny

Ciąg domeny pasuje do danego ciągu domeny, jeśli spełniony jest co najmniej jeden z następujących warunków:

1. Ciąg domeny i ciąg są identyczne. (Należy zauważyć, że zarówno ciąg domeny, jak i ciąg zostaną w tym momencie sprowadzone do kanonicznej małej litery).

2. Obowiązują wszystkie następujące warunki:

   • Łańcuch domeny jest sufiksem łańcucha.

   • Ostatnim znakiem ciągu, który nie jest zawarty w ciągu domeny, jest znak% x2E („.”).

   • Ciąg jest nazwą hosta (tzn. Nie adresem IP).

Zatem domena „subdomain.mydomain.com” pasuje do „mydomain.com”, ale „mydomain.com” NIE pasuje do domeny „subdomain.mydomain.com”

Sprawdź również tę odpowiedź .

W obu przypadkach tak może i jest to domyślne zachowanie zarówno dla IE, jak i Edge.

Pozostałe odpowiedzi dostarczają cennych informacji, ale głównie opisują zachowanie w Chrome. ważne jest, aby pamiętać, że zachowanie jest zupełnie inne w IE. Bardzo pomocny skrypt testowy CMBuckley pokazuje, że w (powiedzmy) Chrome pliki cookie nie są udostępniane między katalogiem głównym a poddomenami, gdy nie określono domeny. Jednak ten sam test w IE pokazuje, że są one udostępniane. Ten przypadek IE jest bliższy opisowi „od domu” w linku CMBuckley www-or-not-www. Wiem, że tak jest, ponieważ mamy system, który używał różnych plików cookie servicestack zarówno w katalogu głównym, jak i subdomenie. Wszystko działało dobrze, dopóki ktoś nie uzyskał do niego dostępu w IE, a dwa systemy walczyły o to, czy plik cookie sesji wygra, dopóki nie wysadzimy pamięci podręcznej.

Uważaj, jeśli pracujesz na localhost! Jeśli przechowujesz swój plik cookie w js w ten sposób:

document.cookie = "key=value;domain=localhost"

Może nie być dostępny dla twojej subdomeny sub.localhost. Aby rozwiązać ten problem, musisz użyć wirtualnego hosta . Na przykład możesz skonfigurować swojego wirtualnego hosta, dzięki ServerName localhost.comczemu będziesz mógł przechowywać swój plik cookie w swojej domenie i poddomenie w następujący sposób:

document.cookie = "key=value;domain=localhost.com"

Proste rozwiązanie

setcookie("NAME", "VALUE", time()+3600, '/', EXAMPLE.COM);

Piąty parametr Setcookie określa (pod) domeny, dla których plik cookie jest dostępny. Ustawienie go na (EXAMPLE.COM) powoduje, że jest ono dostępne dla dowolnej subdomeny (np .: SUBDOMAIN.EXAMPLE.COM)

Odniesienie: http://php.net/manual/en/function.setcookie.php