SameSite=None; – nowe, bezpieczne ustawienia plików cookie

Czwartek, 16 stycznia 2020 r.

Post pochodzi z bloga dla deweloperów Chromium i dotyczy tego, jak zmiany w Chrome mogą w przyszłości wpłynąć na działanie witryny z perspektywy użytkowników.

W maju zespół Chrome ogłosił wprowadzenie domyślnego bezpiecznego modelu plików cookie obsługiwanego przez nowy system klasyfikacji plików cookie (spec). Był to element naszych ciągłych działań mających na celu poprawę prywatności i bezpieczeństwa w internecie.

W lutym 2020 roku zespół Chrome zamierza wdrożyć nowy model w Chrome 80. Mozilla i Microsoft również wykazały zamiar wdrożenia nowego modelu w przeglądarkach Firefox i Edge w zaplanowanych przez siebie terminach. Choć zmiany w Chrome pojawią się dopiero za kilka miesięcy, ważne jest, aby deweloperzy, którzy zarządzają plikami cookie, już dziś ocenili, czy są na nie przygotowani. Ten post zawiera omówienie ogólnych zagadnień. Wskazówki dla dweloperów są dostępne na stronie web.dev w artykule SameSite Cookies Explained (w języku angielskim).

Witryny zwykle integrują usługi zewnętrzne na potrzeby reklamy, rekomendacji treści, widżetów innych firm, umieszczania treści z mediów społecznościowych i innych funkcji. Gdy przeglądasz internet, te usługi zewnętrzne mogą przechowywać pliki cookie w Twojej przeglądarce i używać ich, żeby dostarczać spersonalizowane funkcje lub mierzyć zaangażowanie odbiorców. Z każdym plikiem cookie jest powiązana domena. Jeśli domena powiązana z plikiem cookie jest taka sama jak domena usługi zewnętrznej, a nie jak domena witryny na pasku adresu użytkownika, plik cookie jest uznawany za pochodzący z innej witryny (czyli „zewnętrzny”).

Do mniej oczywistych przypadków użycia plików pochodzących z innych witryn należą sytuacje, gdy podmiot będący właścicielem kilku witryn używa w nich tego samego pliku cookie. Kiedy domena pliku różni się od domeny, która go używa, jest on klasyfikowany jako plik pochodzący z innej witryny lub plik „zewnętrzny”, pomimo że i plik cookie, i witryny są własnością tego samego podmiotu.

Domena witryny jest inna niż domena pliku cookie.

Gdy zasób zewnętrzny na stronie internetowej uzyskuje dostęp do pliku cookie, którego domena jest inna niż domena witryny, mówimy o kontekście pliku cookie pochodzącego z innej witryny lub pliku „zewnętrznego”.

Z kolei kontekst pliku cookie pochodzącego z tej samej witryny (lub pliku „własnego”) ma miejsce, gdy domena pliku cookie jest zgodna z domeną witryny na pasku adresu użytkownika. Pliki cookie pochodzące z tej samej strony są zwykle używane do utrzymywania statusu zalogowanego użytkownika na poszczególnych stronach, zapamiętywania preferencji użytkowników i obsługiwania statystyk witryny.

Domena witryny jest taka sama jak domena pliku cookie.

Gdy zasób zewnętrzny na stronie internetowej uzyskuje dostęp do pliku cookie, którego domena jest taka sama jak domena witryny, którą odwiedza użytkownik, mówimy o kontekście pliku cookie pochodzącego z tej samej witryny lub pliku „własnego”.

Obecnie jeśli plik cookie ma być używany tylko w kontekście tej samej strony, deweloper może zastosować ustawienie SameSite=Lax albo SameSite=Strict, żeby zapobiec dostępowi zewnętrznemu. Jednak tę zalecaną metodę stosuje bardzo niewielu deweloperów, przez co duża liczba plików cookie pochodzących z tej samej witryny jest niepotrzebnie narażana na zagrożenie, na przykład na ataki z wykorzystaniem fałszywych żądań z innej witryny.

Aby nowy domyślny model bezpieczny mógł chronić więcej witryn i ich użytkowników, przyjęto założenie, że o ile nie określono inaczej, wszystkie pliki cookie powinny być chronione przed dostępem z zewnątrz. Deweloperzy muszą użyć nowego ustawienia plików cookie (SameSite=None), żeby wskazać pliki, które mają być dostępne w kontekście innych stron. Jeśli istnieje atrybut SameSite=None, deweloper musi użyć dodatkowego atrybutu Secure, tak aby dostęp do plików cookie pochodzących z innych stron był możliwy tylko przez połączenie HTTPS. Takie rozwiązanie nie eliminuje wprawdzie wszystkich zagrożeń związanych z dostępem z poziomu innej strony, jednak zapewnia ochronę przed atakami sieciowymi.

Bezpośrednia deklaracja użycia plików cookie pochodzących z innych stron nie tylko daje natychmiastowe korzyści związane z bezpieczeństwem, ale też zapewnia większą przejrzystość i umożliwia użytkownikom bardziej świadome dokonywanie wyborów. Na przykład przeglądarki mogą dawać użytkownikom dostęp do opcji zaawansowanych, aby mogli osobno zarządzać plikami cookie pochodzącymi z tej samej witryny, a osobno – tymi z innych witryn.

Egzekwowanie zasad przez Chrome od lutego 2020 roku

Od wersji 80, która będzie dostępna w lutym, Chrome będzie klasyfikować pliki cookie, które nie mają zadeklarowanej wartości SameSite, jako pliki SameSite=Lax. Dostęp z zewnątrz będzie możliwy tylko w przypadku plików cookie z ustawieniem zabezpieczeń SameSite=None i tylko przez zabezpieczone połączenie. Nadal będziemy aktualizować skrypty śledzenia stanu platformy Chrome dotyczące wartości SameSite=None i atrybutu Secure, podając najnowsze informacje o wprowadzeniu nowych rozwiązań.

Firma Mozilla potwierdziła obsługę nowego modelu klasyfikacji plików cookie i zamiar wdrożenia w przeglądarce Firefox wymagań dotyczących wartości SameSite=None służących zabezpieczniu połączenia w przypadku plików cookie pochodzących z innych witryn. Firma Microsoft ogłosiła, że planuje rozpocząć wdrażanie bezpiecznego modelu w ramach eksperymentu w przeglądarce Microsoft Edge 80.

Jak się przygotować; znane problemy

Jeśli zarządzasz plikami cookie pochodzącymi z innych stron, musisz zastosować do nich ustawienie zabezpieczeń SameSite=None. Dla większości deweloperów implementacja tego rozwiązania powinna być prosta, ale zdecydowanie zachęcamy, aby już teraz rozpocząć testy, które pozwolą wykryć ewentualne trudności i szczególne przypadki, na przykład:

  • Jeszcze nie wszystkie języki i biblioteki obsługują wartość Brak, przez co deweloperzy muszą ustawiać bezpośrednio nagłówek pliku cookie. W tym repozytorium GitHub znajdują się instrukcje implementacji ustawienia zabezpieczeń SameSite=None w różnych językach, bibliotekach i platformach.
  • Niektóre przeglądarki, w tym niektóre wersje Chrome, Safari i UC Browser, mogą interpretować wartość None w niezamierzony sposób – wówczas programiści muszą kodować dla tych klientów wyjątki. Obejmuje to także komponenty WebView na Androida w starszych wersjach Chrome. Oto lista znanych nieobsługiwanych klientów.
  • Zalecamy, aby deweloperzy aplikacji deklarowali odpowiednie ustawienia SameSite cookie komponentów WebViews na Androida na podstawie wersji Chrome obsługujących wartość None, zarówno w przypadku plików cookie, do których dostęp jest możliwy przy użyciu nagłówków HTTP(S), jak i tych, do których dostęp umożliwia interfejs CookieManager API komponentów WebView na Androida. Nowy model będzie jednak egzekwowany w przypadku komponentów WebView na Androida dopiero później.
  • Jeśli niektóre usługi, takie jak logowanie jednokrotne lub aplikacje wewnętrzne, nie będą w lutym gotowe na nowe wymagania, administratorzy IT mogą potrzebować specjalnych zasad, żeby tymczasowo przywrócić Chrome do starszej wersji.
  • Jeśli używasz plików cookie zarówno w kontekście innych stron, jak i tej samej strony, rozważ używanie osobnych plików, żeby móc korzystać z zalet wartości SameSite=Lax w kontekście tej samej strony.

W artykule SameSite Cookies Explained (w języku angielskim) znajdziesz bardziej szczegółowe wskazówki dotyczące powyższych sytuacji oraz listę kanałów, którymi można zgłaszać problemy i pytania.

Aby przetestować wpływ nowych mechanizmów Chrome w witrynie lub plikach cookie, którymi zarządzasz, otwórz stronę chrome://flags w Chrome w wersji 76 lub nowszej, a następnie włącz eksperymenty „SameSite by default cookies” i „Cookies without SameSite must be secure”. Te eksperymenty będą też automatycznie włączone dla części użytkowników Chrome 79 w wersji beta. Niektórzy użytkownicy wersji beta z włączonymi eksperymentami mogą napotkać problemy ze zgodnością z usługami, które jeszcze nie obsługują nowego modelu. Eksperymenty w wersji beta można wyłączyć na stronie chrome://flags.

Jeśli zarządzasz plikami cookie, które są używane tylko w kontekście tej samej strony (pliki cookie pochodzące z tej samej strony), nie musisz nic robić. Chrome automatycznie uniemożliwi podmiotom zewnętrznym dostęp do tych plików, nawet jeśli nie użyjesz atrybutu SameSite lub nie ustawisz w nim żadnej wartości. Zdecydowanie zalecamy jednak, aby zastosować odpowiednią wartość SameSite (Lax lub Strict), zamiast polegać na domyślnym działaniu przeglądarki, ponieważ nie wszystkie przeglądarki domyślnie chronią pliki cookie pochodzące z tej samej strony.

Jeśli obawiasz się o to, czy podwykonawcy lub dostawcy usług Twojej witryny są gotowi na tę zmianę, w Chrome w wersji 77 lub nowszej możesz sprawdzić ostrzeżenia konsoli Narzędzi dla programistów, które pojawiają się, gdy strona zawiera pliki cookie pochodzące z innych stron bez wymaganych ustawień:

Plik cookie powiązany z zasobem z innej witryny w domenie (domena pliku cookie) nie ma skonfigurowanego atrybutu „SameSite”.

Niektórzy dostawcy (w tym niektóre usługi Google) wprowadzą w najbliższych miesiącach niezbędne zmiany, które będą wymagane w Chrome od wersji 80 (od lutego). Warto skontaktować się ze swoimi partnerami, aby potwierdzić ich gotowość na te zmiany.