Schemeryzująca tę samą witrynę

Definicja terminu „ta sama witryna” wciąż będzie obejmować schemat adresu URL, dlatego linki między wersjami HTTP i HTTPS witryny liczone są teraz jako żądania z innych witryn. Przejdź domyślnie na HTTPS, aby uniknąć problemów, gdy to możliwe, lub przeczytaj szczegółowe informacje o tym, jakie wartości atrybutów SameSite są potrzebne.

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

Parametr Schemeful Same-Site zmienia definicję witryny (internetowej) z samej domeny, którą można zarejestrować, na schemat z domeną, którą można zarejestrować. Więcej informacji i przykładów znajdziesz w artykule Omówienie terminów „ta sama witryna” i „ta sama witryna”.

Dobra wiadomość jest taka, że jeśli Twoja witryna jest już w pełni uaktualniona do HTTPS, nie musisz się niczym martwić. Nic się dla Ciebie nie zmieni.

Jeśli Twoja witryna nie została jeszcze w pełni uaktualniona, potraktuj to priorytetowo. Jeśli jednak zdarzają się sytuacje, w których użytkownicy witryny przechodzą z protokołu HTTP na HTTPS, poniżej przedstawiamy niektóre z tych typowych scenariuszy i powiązane z nimi zachowanie plików cookie SameSite.

Te zmiany możesz włączyć do testowania zarówno w przeglądarkach Chrome, jak i w Firefoksie.

  • W Chrome 86 włącz about://flags/#schemeful-same-site. Postęp możesz śledzić na stronie stanu Chrome.
  • W przeglądarce Firefox w wersji 79 ustaw network.cookie.sameSite.schemeful na true przez about:config. Postępy możesz śledzić na stronie problemu z Bugzilla.

Jedną z głównych przyczyn zmiany ustawienia SameSite=Lax jako domyślnego dla plików cookie była ochrona przed fałszowaniem żądań z innych witryn (CSRF). Jednak niezabezpieczony ruch HTTP nadal daje hakerom możliwość manipulowania plikami cookie, które zostaną wykorzystane w bezpiecznej wersji HTTPS witryny. Utworzenie tej dodatkowej granicy między schematami zapewnia jeszcze lepszą ochronę przed takimi atakami.

Typowe scenariusze testów krzyżowych

Przechodzenie między wersjami witryny należącymi do różnych schematów (np. połączenie z adresem http://site.example z adresem https://site.example) wcześniej umożliwiało wysyłanie plików cookie SameSite=Strict. Jest to teraz traktowane jako nawigacja między witrynami, co oznacza, że pliki cookie SameSite=Strict będą blokowane.

Nawigacja w ramach schematu aktywowana przez kliknięcie linku w niezabezpieczonej wersji HTTP witryny prowadzącej do bezpiecznej wersji HTTPS. SameSite=Strict pliki cookie zablokowane, SameSite=Lax i SameSite=None; dozwolone są bezpieczne pliki cookie.
Nawigacja między schematami z HTTP na HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Zablokowano ⛔ Zablokowano
SameSite=Lax ✓ Dozwolone ✓ Dozwolone
SameSite=None;Secure ✓ Dozwolone ⛔ Zablokowano

Wczytuję zasoby podrzędne

Wszelkie wprowadzone tutaj zmiany powinny być traktowane jako tymczasowa poprawka dopiero w trakcie wprowadzania pełnej wersji protokołu HTTPS.

Przykładami zasobów podrzędnych są obrazy, elementy iframe i żądania sieciowe wysyłane za pomocą XHR lub Fetch.

Wczytywanie zasobu podrzędnego zasobu między schematami na stronie umożliwiałoby wcześniej wysyłanie lub ustawianie plików cookie SameSite=Strict lub SameSite=Lax. Teraz jest ono traktowane tak samo jak w przypadku innych zasobów podrzędnych lub pochodzących z innych witryn, co oznacza, że wszystkie pliki cookie SameSite=Strict lub SameSite=Lax będą blokowane.

Dodatkowo nawet jeśli przeglądarka zezwala na wczytywanie zasobów z niezabezpieczonych schematów na bezpiecznej stronie, w przypadku tych żądań wszystkie pliki cookie są blokowane, ponieważ pliki cookie innych firm lub innych witryn wymagają klasy Secure.

Zasób podrzędny schematu krzyżowego powstały z zasobu z bezpiecznej wersji HTTPS witryny uwzględnionej w niezabezpieczonej wersji HTTP. SameSite=Strict i SameSite=Lax zablokowane oraz SameSite=None; dozwolone są bezpieczne pliki cookie.
Strona HTTP zawierająca zasób podrzędny danych z innego schematu przez HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Zablokowano ⛔ Zablokowano
SameSite=Lax ⛔ Zablokowano ⛔ Zablokowano
SameSite=None;Secure ✓ Dozwolone ⛔ Zablokowano

OPUBLIKOWANIE formularza

Publikowanie danych między wersjami witryny korzystającymi z innych schematów umożliwiało wcześniej wysyłanie plików cookie z ustawieniem SameSite=Lax lub SameSite=Strict. Teraz jest to traktowane jako żądanie POST w innej witrynie – można wysłać tylko pliki cookie (SameSite=None). Taki scenariusz możesz napotkać w witrynach, które domyślnie wyświetlają wersję niezabezpieczoną, ale przełącz użytkowników na wersję bezpieczną po przesłaniu formularza logowania lub wymeldowania.

Tak jak w przypadku zasobów podrzędnych, jeśli żądanie przechodzi z bezpiecznego, np. HTTPS do niezabezpieczonego, np. HTTP, kontekst powoduje zablokowanie wszystkich plików cookie w przypadku tych żądań, ponieważ pliki cookie innych firm lub innych witryn wymagają klasy Secure.

Przesłanie formularza z innego schematu powstałego w wyniku przesłania formularza w niezabezpieczonej wersji HTTP witryny w bezpiecznej wersji HTTPS. SameSite=Strict i SameSite=Lax zablokowane oraz SameSite=None; dozwolone są bezpieczne pliki cookie.
Przesyłanie formularzy z różnych schematów z HTTP do HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Zablokowano ⛔ Zablokowano
SameSite=Lax ⛔ Zablokowano ⛔ Zablokowano
SameSite=None;Secure ✓ Dozwolone ⛔ Zablokowano

Jak mogę przetestować swoją witrynę?

Narzędzia i komunikatory dla deweloperów są dostępne w przeglądarkach Chrome i Firefox.

Od wersji Chrome 86 karta Problem w Narzędziach deweloperskich będzie zawierać problemy Schemeful Same-Site. Możesz zauważyć takie problemy z witryną.

Problemy z nawigacją:

  • „Przejdź całkowicie na HTTPS, aby nadal wysyłać pliki cookie w odpowiedzi na żądania tej samej witryny” – ostrzeżenie, że plik cookie zostanie zablokowany w przyszłej wersji Chrome.
  • „Przejdź całkowicie na HTTPS, aby pliki cookie były wysyłane w odpowiedzi na żądania z tej samej witryny” – ostrzeżenie, że plik cookie został zablokowany.

Problemy z wczytywaniem zasobu podrzędnego:

  • „Przejdź całkowicie na HTTPS, aby pliki cookie nadal były wysyłane do podzasobów tej samej witryny” lub „Przejdź całkowicie na HTTPS, aby nadal zezwalać na tworzenie plików cookie przez zasoby podrzędne tej samej witryny” – ostrzeżenie, że plik cookie zostanie zablokowany w przyszłej wersji Chrome.
  • „Przejdź całkowicie na HTTPS, aby pliki cookie były wysyłane do podzasobów tej samej witryny” lub „Przejdź całkowicie na HTTPS, aby umożliwić tworzenie plików cookie przez podzasoby tej samej witryny” – spowoduje to ostrzeżenie o zablokowaniu pliku cookie. To ostatnie ostrzeżenie może się też pojawić podczas wysyłania formularza POST.

Więcej informacji znajdziesz we Wskazówkach dotyczących testowania i debugowania w przypadku Schemeful Same-Site.

W przeglądarce Firefox w wersji 79 i w przypadku ustawienia network.cookie.sameSite.schemeful na true przez about:config konsola wyświetla komunikat w przypadku problemów z technologią Schemeful Same-Site. W witrynie mogą się pojawić następujące elementy:

  • „Plik cookie cookie_name zostanie wkrótce potraktowany jako plik cookie z innej witryny dotyczący http://site.example/, ponieważ schemat nie jest zgodny”.
  • „Plik cookie cookie_name został traktowany jako pochodzący z innej witryny w stosunku do http://site.example/, ponieważ schemat jest niezgodny”.

Najczęstsze pytania

Moja witryna jest już w pełni dostępna przez HTTPS. Dlaczego widzę problemy w Narzędziach deweloperskich w mojej przeglądarce?

Niektóre z Twoich linków i zasobów podrzędnych mogą nadal wskazywać niezabezpieczone adresy URL.

Jednym ze sposobów rozwiązania tego problemu jest użycie HTTP Strict-Transport-Security (HSTS) i dyrektywa includeSubDomain. HSTS + includeSubDomain, nawet jeśli jedna z Twoich stron przypadkowo umieści niezabezpieczony link, przeglądarka automatycznie użyje wersji bezpiecznej.

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

Aby chronić użytkowników, zdecydowanie zalecamy przejście na protokół HTTPS w witrynie. Jeśli jednak nie jest to możliwe, można skontaktować się z dostawcą usług hostingowych i zapytać, czy może skorzystać z takiej opcji. Jeśli samodzielnie hostujesz certyfikat, Let's Encrypt udostępnia wiele narzędzi do zainstalowania i skonfigurowania 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 zadziała, spróbuj złagodzić zabezpieczenie SameSite, które dotyczy plików cookie, których dotyczy problem.

  • Jeśli blokowane są tylko pliki cookie SameSite=Strict, możesz obniżyć poziom ochrony do Lax.
  • Jeśli blokowane są pliki cookie Strict i Lax, a pliki cookie są wysyłane pod bezpieczny adres URL lub z niego wysyłane, możesz obniżyć poziom zabezpieczeń do None.
    • To obejście nie zadziała, jeśli adres URL, pod który wysyłasz pliki cookie (lub z którego je konfigurujesz), nie jest bezpieczny. Dzieje się tak, ponieważ SameSite=None wymaga atrybutu Secure w plikach cookie, co oznacza, że mogą one nie być wysyłane ani ustawiane przez niezabezpieczone połączenie. W takim przypadku nie będziesz mieć dostępu do tego pliku cookie, dopóki witryna nie zostanie uaktualniona do HTTPS.
    • Pamiętaj, że jest to sytuacja tymczasowa, ponieważ pliki cookie innych firm zostaną z czasem całkowicie wycofane.

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

Pliki cookie bez atrybutu SameSite są traktowane tak, jakby zawierały parametr SameSite=Lax. Te pliki cookie też są objęte tym samym działaniem w ramach różnych schematów. Pamiętaj, że tymczasowy wyjątek od niebezpiecznych metod nadal obowiązuje. Więcej informacji znajdziesz w artykule na temat łagodzenia Lax i POST w odpowiedziach na SameSitenajczęstsze pytania w Chromium.

Jaki ma to wpływ na WebSockets?

Połączenia WebSocket nadal będą uznawane za tę samą witrynę, jeśli mają taki sam poziom zabezpieczeń jak strona.

Ta sama witryna:

  • wss:// połączenie od: https://
  • ws:// połączenie od: http://

W innych witrynach:

  • wss:// połączenie od: http://
  • ws:// połączenie od: https://

Fot. Julissa Capdevilla w serwisie Unsplash