Czy subdomain.example.com może ustawić plik cookie, który może być odczytany przez example.com?

Po prostu nie mogę uwierzyć, że jest to takie trudne do ustalenia.

Nawet po przeczytaniu RFC nie jest dla mnie jasne, czy serwer w domenie subdomain.example.com może ustawić plik cookie, który może być odczytany przez example.com.

subdomain.example.com może ustawić plik cookie, którego atrybut domeny to .example.com. RFC 2965 wydaje się wyraźnie stwierdzać, że taki plik cookie nie zostanie wysłany do example.com, ale jednocześnie mówi również, że jeśli ustawisz Domain = example.com, kropka zostanie dodana, tak jakbyś powiedział .example.com. Podsumowując, wydaje się, że oznacza to, że jeśli example.com zwraca zestaw plików cookie z Domain = example.com, to nie odzyskuje tego pliku cookie! To nie może być prawda.

Czy ktoś może wyjaśnić, jakie naprawdę są reguły?

Cytując z tego samego RFC2109, który czytasz:

       * Zestaw plików cookie z hosta żądania x.foo.com dla domeny = .foo.com
         być uznanym.

Więc subdomain.example.commożna ustawić plik cookie dla .example.com. Jak na razie dobrze.

       Poniższe zasady dotyczą wyboru odpowiednich wartości plików cookie
       spośród wszystkich plików cookie, które posiada agent użytkownika.

       Wybór domeny
            W pełni kwalifikowana nazwa hosta serwera źródłowego musi być zgodna z domeną
            atrybut domeny pliku cookie

Czy mamy dopasowanie do domeny?

   * A jest ciągiem FQDN i ma postać NB, gdzie N jest niepustą nazwą
     ciąg, B ma postać .B ', a B' jest ciągiem FQDN. (Więc, Xycom
     dopasowanie do domeny .y.com, ale nie y.com).

Ale teraz example.comnie pasuje .example.comdo domeny zgodnie z definicją. Ale www.example.com(lub jakakolwiek inna „niepusta nazwa” w domenie) by to zrobiła. Te RFC są teoretycznie nieaktualne przez RFC2965 , który dyktuje rzeczy o wymuszaniu wiodącej kropki dla domen w Set-Cookie2operacjach.

Ważniejszy, jak zauważa @Tony, jest świat rzeczywisty. Aby rzucić okiem na to, co robią faktyczne programy użytkownika, zobacz

NsCookieService.cpp Firefoksa 3

i

Plik cookie_monster.cc w Chrome

Dla perspektywy co do rzeczywistych miejsc robią spróbuj grać z wgetużyciem --save-cookies, --load-cookiesi --debugzobaczyć, co się dzieje.

Prawdopodobnie przekonasz się, że w rzeczywistości większość witryn używa kombinacji Set-Cookiestarszych specyfikacji RFC z wartościami „Host”, domyślnie bez początkowej kropki (jak robi to twitter.com ) lub ustawiania wartości domeny (z kropką wiodącą) i przekierowywania na serwer taki jak www.example.com(jak google.com ).

Jeśli przeglądarka implementuje standard RFC 6265 , co w tym momencie powinna robić każda współczesna przeglądarka, wówczas zestaw plików cookie dla .example.combędzie ignorował kropkę wiodącą (sekcja 5.2.3), a następnie plik cookie zostanie wysłany do nagiej domeny i do wszystkich poddomeny.

Nie polegaj na tym zachowaniu, jeśli masz znaczny ruch ze starszych przeglądarek; ten RFC pochodzi tylko z 2011 roku.

To nie powinno być możliwe. Jednak, jak powiedziałeś, ponieważ nie jest to szeroko udokumentowany standard, zależy to od używanego oprogramowania.

Większość współczesnych przeglądarek przestrzega zdefiniowanego „modelu bezpieczeństwa sieci”. Model ten skutecznie zarządza zachowaniem przeglądarek w zakresie bezpieczeństwa, np. Plików cookie (w szczególności sposobu, w jaki będą one odsyłane z powrotem na dowolną stronę internetową). Model ma również zasadę, że „przeglądarki nie wysyłają plików cookie do nazw domen, które ich nie ustawiły”.

Biorąc to pod uwagę, domena.com powinna mieć możliwość ustawiania plików cookie dla js.domain.com. js.domain.com może jednak ustawić pliki cookie tylko dla siebie. Wszystko to zależy od używanej przeglądarki.