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

420

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?

adam0101
źródło
3
Tak, możesz .. proszę zobaczyć link poniżej codeguru.com/csharp/csharp/cs_internet/article.php/c19417/...
Rahul Jain
Ściśle związane: stackoverflow.com/questions/3089199/...
Ciro Santilli 法轮功 冠状 病 六四 事件 法轮功
czy możesz spojrzeć na to pytanie stackoverflow.com/questions/38351769/…
Jayavardhan Gange
1
@ adam0101 Co zrobić, jeśli domena i subdomena są hostowane na innym serwerze?
user3782114,
3
@ user3782114, nie ma znaczenia, czy są na różnych serwerach. W moim przypadku były one nie tylko na różnych serwerach, ale każda domena była równoważona obciążeniem na wielu serwerach. Jedną z rzeczy, które nas nieco potknęły, było to, że niższe środowiska (programista, test, uat itp.) Zaczęły udostępniać ten sam plik cookie, gdy to zrobiliśmy, ponieważ nazwaliśmy je jako „dev.oursite.com”, „test”. oursite.com ”, itp. Sztuką (przynajmniej w .Net) jest wygenerowanie osobnego klucza komputera dla każdego środowiska i zapisanie go w pliku Web.config (zakładając, że zmienisz konfigurację dla każdego środowiska).
adam0101

Odpowiedzi:

653

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

cmbuckley
źródło
3
Dzięki; Dodałem notatkę o znaczeniu kropki.
cmbuckley
2
Nie rozumiem, dlaczego po prostu nie umieścisz wiodącego słowa „”. w domenie dla maksymalnej kompatybilności ze starym i nowym
Alan Macdonald
12
W starym standardzie plik cookie z domain=.mydomain.comnie jest prawidłowy dla samej domeny mydomain.com, więc dwa RFC nie są ze sobą kompatybilne.
cmbuckley,
4
@Frank, tak, wiem. Mój komentarz miał wyjaśnić, że moje pytanie dotyczy udostępniania plików cookie między domeną a subdomeną, a NIE między dwiema subdomenami.
adam0101
3
Nie jestem pewien, gdzie to umieścić, więc wybieram komentarze do zaakceptowanej odpowiedzi. Zajęło to dużo czasu i nieudane eksperymenty, aby udowodnić powyższe na moim komputerze lokalnym, aż przyszło mi do głowy, że powinienem zadzwonić do komputera lokalnego z kropką w nazwie. Na przykład „localhost.com” lub coś w tym rodzaju. Następnie wszystkie zachowania „ustawiania plików cookie” rozpoczęły się zgodnie z objaśnieniami zapisanymi tutaj w tej odpowiedzi. Mam nadzieję, że to może komuś pomóc.
Cesc
32

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ę /:

akostadinov
źródło
4
Wygląda na to, że zgadzam się z tym, co mówię: jeśli nie określisz domain, plik cookie jest używany tylko dla hosta żądań. Oznacza to, że Set-Cookie: name=valuez mydomain.comnie będą wysyłane żądania do poddomen. Zagraj też w ten skrypt testowy .
cmbuckley
@cmbuckley, ok, to co powiedziałeś wydaje się poprawne. Przeredaguję moją odpowiedź. Dziękuję za zwrócenie na to uwagi.
akostadinov
Trzeba zaznaczyć, że sekcja 4.1.2 (pierwszy cytat) nie jest normatywna ...
Velda
dzięki za link cmbuckley. miło przetestować, jak to działa szybko.
lawphotog
22

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.

Lambambda
źródło
1
To sprawia, że ​​zastanawiam się, czy istnieją osobne specyfikacje opisujące zachowanie httponlyplików cookie w porównaniu z rodzajem plików cookie, które tworzysz.
adam0101
3
Dokumenty, które opublikowałeś, nie zgadzają się z twoimi stwierdzeniami. Pierwsze 2 przykłady nie są równoważne ( domainatrybut powoduje, że plik cookie działa w subdomenach; żaden taki atrybut nie działa). Wiodące kropki są w najlepszym wypadku ignorowane, aw najgorszym aktywnie blokowane.
cmbuckley
jest to najlepsze rozwiązanie, jeśli nie chcesz polegać na nagłówkach hosta. Sprawdziłem i działa
Szymon
14

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

Księgowy م
źródło
To była dla mnie najbardziej pomocna odpowiedź.
Toby
3

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.

DannyW
źródło
0

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"
Alexandre97122
źródło
-12

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

Lawes
źródło
17
To pytanie nie jest specyficzne dla PHP, nie sądzę, że kwalifikuje się jako prawidłowe.
sergelerator
1
Sergelerator, nie zadałem pytania. Odpowiadałem na PO.
Lawes
4
@Lawes Uważam, że sergelator oznacza, że ​​pytanie PO nie jest specyficzne dla PHP, podczas gdy twoja odpowiedź wydaje się być rozwiązaniem opartym wyłącznie na PHP, dlatego nie kwalifikuje się do pytania PO.
Mirage