Schemeryzująca tę samą witrynę

Definicja „tej samej witryny” została rozszerzona o schemat adresu URL, więc linki między wersjami HTTP i HTTPS witryny są teraz traktowane jako żądania między witrynami. Przełącz się domyślnie na HTTPS, aby uniknąć problemów, lub przeczytaj więcej o tym, jakie wartości atrybutu SameSite są potrzebne.

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

Schemat z opcją Same-Sitemodyfikuje definicję witryny (internetowej) z tylko domeny nadającej się do rejestracji na schemat + domenę nadającą się do rejestracji. Więcej informacji i przykładów znajdziesz w artykule „Rozróżnianie między „tą samą witryną” a „tym samym źródłem””.

Dobra wiadomość: jeśli Twoja witryna jest już w pełni przeniesiona na protokół HTTPS, nie musisz się o nic martwić. Nic się nie zmieni.

Jeśli Twoja witryna nie jest jeszcze w pełni zaktualizowana, powinna być to priorytet. Jeśli jednak w Twojej witrynie zdarza się, że użytkownicy przechodzą między HTTP a HTTPS, w dalszej części tego artykułu znajdziesz opis niektórych typowych scenariuszy i powiązanego z nimi zachowania plików cookie SameSite.

Możesz włączyć te zmiany do testowania zarówno w Chrome, jak i w Firefox.

  • W Chrome 86 włącz about://flags/#schemeful-same-site. Śledź postępy na stronie stanu Chrome.
  • Od wersji 79 Firefoxa ustaw network.cookie.sameSite.schemeful na true za pomocą about:config. Śledź postępy za pomocą problemu w Bugzilla.

Jednym z głównych powodów zmiany domyślnego ustawienia plików cookie na SameSite=Lax była ochrona przed fałszowaniem żądań między witrynami (CSRF). Niebezpieczny ruch HTTP nadal daje atakującym sieć możliwość manipulowania plikami cookie, które będą używane w bezpiecznej wersji strony internetowej obsługującej HTTPS. Utworzenie dodatkowej granicy między schematami na różnych stronach zapewnia dodatkową ochronę przed tymi atakami.

Typowe scenariusze dotyczące różnych schematów

Przechodzenie między wersjami witryny w różnych schematach (np. kliknięcie linku z http://site.example na https://site.example) pozwalało wcześniej na wysyłanie plików cookie SameSite=Strict. Jest ona teraz traktowana jako nawigacja między witrynami, co oznacza, że pliki cookie SameSite=Strict zostaną zablokowane.

Przejście między schematami wywołane kliknięciem linku w niezabezpieczonej wersji witryny (HTTP) do bezpiecznej wersji (HTTPS). Pliki cookie SameSite=Strict są blokowane, a pliki cookie SameSite=Lax i SameSite=None; Secure są dozwolone.
Przechodzenie między schematami z HTTP do HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Zablokowany ⛔ Zablokowany
SameSite=Lax ✓ Dozwolone ✓ Dozwolone
SameSite=None;Secure ✓ Dozwolone ⛔ Zablokowany

Wczytuję zasoby podrzędne

Wprowadzone tutaj zmiany powinny być traktowane tylko jako tymczasowe rozwiązanie, dopóki nie przełączysz się całkowicie na HTTPS.

Przykłady podzasobów to m.in. obrazy, ramki iframe i zapytania sieciowe wysyłane za pomocą XHR lub Fetch.

Wcześniej wczytywanie na stronie zasobu podrzędnego w ramach różnych schematów umożliwiało wysyłanie lub ustawianie plików cookie SameSite=Strict lub SameSite=Lax. Teraz jest on traktowany tak samo jak inne zasoby podrzędne pochodzące z innych witryn lub z wielu witryn, co oznacza, że wszystkie pliki cookie SameSite=Strict lub SameSite=Lax zostaną zablokowane.

Nawet jeśli przeglądarka zezwala na wczytywanie zasobów z niebezpiecznych schematów na zabezpieczonej stronie, wszystkie pliki cookie będą blokowane w przypadku tych żądań, ponieważ pliki cookie innych firm lub pochodzące z innych stron wymagają Secure.

Zasób podrzędny w ramach różnych schematów pochodzący z zasobu z bezpiecznej wersji witryny HTTPS, który jest uwzględniony w niebezpiecznej wersji HTTP. Blokowanie plików cookie SameSite=Strict i SameSite=Lax oraz zezwalanie na pliki cookie SameSite=None; Secure.
Strona HTTP zawierająca zasób podrzędny w ramach różnych schematów w protokole HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Zablokowany ⛔ Zablokowany
SameSite=Lax ⛔ Zablokowany ⛔ Zablokowany
SameSite=None;Secure ✓ Dozwolone ⛔ Zablokowany

Przesyłanie formularza za pomocą metody POST

Wcześniej publikowanie między wersjami witryny w różnych schematach umożliwiało wysyłanie plików cookie ustawionych za pomocą wartości SameSite=Lax lub SameSite=Strict. Teraz jest on traktowany jako żądanie POST w wielu witrynach – można wysyłać tylko pliki cookie SameSite=None. Taki scenariusz może wystąpić w przypadku stron, które domyślnie wyświetlają wersję niezabezpieczoną, ale po przesłaniu formularza logowania lub płatności przekierowują użytkowników do wersji zabezpieczonej.

Podobnie jak w przypadku zasobów podrzędnych, jeśli żądanie pochodzi z bezpiecznego kontekstu (np. HTTPS) do niebezpiecznego kontekstu (np. HTTP), wszystkie pliki cookie zostaną zablokowane w tych żądaniach, ponieważ pliki cookie innych firm lub pliki cookie między witrynami wymagają Secure.

Przesyłanie formularza w ramach różnych schematów, gdy formularz w niezabezpieczonej wersji witryny HTTP jest przesyłany do bezpiecznej wersji witryny HTTPS. Blokowanie plików cookie SameSite=Strict i SameSite=Lax oraz zezwalanie na pliki cookie SameSite=None; Secure.
Przesyłanie formularzy w ramach różnych schematów z protokołu HTTP do HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Zablokowany ⛔ Zablokowany
SameSite=Lax ⛔ Zablokowany ⛔ Zablokowany
SameSite=None;Secure ✓ Dozwolone ⛔ Zablokowany

Jak przetestować swoją witrynę?

Narzędzia i komunikaty dla deweloperów są dostępne w Chrome i Firefox.

Od wersji 86 karta Problemy w Narzędziach deweloperskich będzie zawierać problemy z SameSite w ramach schematu. W Twojej witrynie mogą być podświetlone następujące problemy:

Problemy z nawigacją:

  • „Przejdź całkowicie na HTTPS, aby nadal wysyłać pliki cookie w żądaniach na tym samym koncie” – ostrzeżenie, że plik cookie będzie zablokowany w przyszłej wersji Chrome.
  • „Przenieś wszystko na HTTPS, aby pliki cookie były wysyłane w przypadku żądań w ramach tej samej witryny” – ostrzeżenie, że plik cookie został zablokowany.

Problemy z wczytywaniem podelementów:

  • „Przenieś wszystko na HTTPS, aby nadal wysyłać pliki cookie do zasobów podrzędnych w tej samej witrynie” lub „Przenieś wszystko na HTTPS, aby nadal zezwalać na zapisywanie plików cookie przez zasoby podrzędne w tej samej witrynie” – ostrzeżenia, że pliki cookie będą blokowane w przyszłej wersji Chrome.
  • „Pełna migracja do HTTPS w celu wysyłania plików cookie do zasobów podrzędnych w tej samej witrynie” lub „Pełna migracja do HTTPS w celu umożliwienia ustawiania plików cookie przez zasoby podrzędne w tej samej witrynie” – ostrzeżenia, że plik cookie został zablokowany. Drugie ostrzeżenie może się też pojawić podczas przesyłania formularza.

Więcej informacji znajdziesz w artykule Wskazówki dotyczące testowania i debugowania w przypadku SameSite: Strict-G na poziomie domeny.

Od wersji 79 przeglądarki Firefox, gdy network.cookie.sameSite.schemeful jest ustawiona na true za pomocą about:config, konsola wyświetla komunikat o problemach z usługami w tej samej witrynie. W swojej witrynie możesz zobaczyć:

  • „Plik cookie cookie_name będzie wkrótce traktowany jako plik cookie w wielu witrynach w stosunku do pliku http://site.example/, ponieważ schemat nie pasuje”.
  • „Plik cookie cookie_name został potraktowany jako plik cookie dotyczący wielu witryn w kontekście witryny http://site.example/, ponieważ schemat nie pasuje”.

Najczęstsze pytania

Moja witryna jest już w pełni dostępna w protokole HTTPS. Dlaczego widzę problemy w narzędziach programisty w przeglądarce?

Możliwe, że niektóre z linków i podresursów nadal wskazują niepewne adresy URL.

Jednym ze sposobów rozwiązania tego problemu jest użycie HTTP Strict-Transport-Security (HSTS) i dyrektywy includeSubDomain. Dzięki HSTS + includeSubDomain nawet wtedy, gdy jedna z Twoich stron zawiera przypadkowo niezabezpieczony link, przeglądarka automatycznie użyje bezpiecznej wersji.

Co zrobić, jeśli nie mogę przejść na HTTPS?

Zdecydowanie zalecamy przeniesienie całej witryny na protokół HTTPS, aby chronić użytkowników. Jeśli nie możesz tego zrobić samodzielnie, skontaktuj się z dostawcą usług hostingowych i zapytaj, czy może Ci to umożliwić. Jeśli hostujesz samodzielnie, Let's Encrypt udostępnia kilka narzędzi do instalowania i konfigurowania certyfikatu. Możesz też rozważyć przeniesienie witryny za sieć CDN lub inny serwer proxy, który może zapewnić połączenie HTTPS.

Jeśli to nie jest możliwe, spróbuj osłabić ochronę SameSite w przypadku plików cookie, których dotyczy problem.

  • Jeśli zablokowane są tylko pliki cookie SameSite=Strict, możesz obniżyć poziom ochrony do Lax.
  • Jeśli pliki cookie Strict i Lax są blokowane, a pliki cookie są wysyłane do (lub ustawiane z poziomu) bezpiecznego adresu URL, możesz obniżyć poziom ochrony do None.
    • To obejście nie zadziała, jeśli adres URL, na który wysyłasz pliki cookie (lub z którego je wysyłasz), jest niezabezpieczony. Dzieje się tak, ponieważ SameSite=None wymaga atrybutu Secure w plikach cookie, co oznacza, że pliki cookie nie mogą być wysyłane ani ustawiane przez niezabezpieczone połączenie. W tym przypadku nie będziesz mieć dostępu do tego pliku cookie, dopóki nie przekształcisz witryny na HTTPS.
    • Pamiętaj, że jest to tylko tymczasowe rozwiązanie, ponieważ w przyszłości pliki cookie innych firm zostaną całkowicie wycofane.

Jak to wpłynie na moje pliki cookie, jeśli nie podam atrybutu SameSite?

Pliki cookie bez atrybutu SameSite są traktowane tak, jakby miały ustawioną wartość SameSite=Lax, a do tych plików cookie stosuje się takie samo zachowanie w przypadku różnych schematów. Pamiętaj, że tymczasowy wyjątek dotyczący niebezpiecznych metod nadal obowiązuje. Więcej informacji znajdziesz w Pytaniach i odpowiedziach na temat metody Lax + POST w ChromiumSameSite.

Jaki to ma wpływ na WebSockets?

Połączenia WebSocket będą nadal uważane za połączenia w ramach tej samej witryny, jeśli mają ten sam poziom zabezpieczeń co strona.

Same-site:

  • Połączenie wss:// z https://
  • Połączenie ws:// z http://

W wielu witrynach:

  • Połączenie wss:// z http://
  • Połączenie ws:// z https://

Zdjęcie: Julissa Capdevilla z Unsplash