Schemeryzująca tę samą witrynę

Definicja słowa „ta sama witryna” uwzględnia schemat adresów URL, więc linki między wersjami HTTP i HTTPS witryny są liczone jako żądania z innych witryn. Domyślnie przejdź na protokół HTTPS, aby uniknąć problemów, gdy to możliwe, lub zapoznaj się ze szczegółowymi informacjami na temat wymaganych wartości atrybutów SameSite.

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

Sztuczne Ta sama witryna zmienia definicję witryny (internetowej) z domeny, którą można zarejestrować, na schemat + domena, którą można zarejestrować. Więcej informacji i przykładów znajdziesz tutaj: Co to jest „ta sama witryna” oraz „same-origin”.

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

Jeśli witryna nie została jeszcze w pełni uaktualniona, to jest priorytetem. Jeśli jednak zdarzają się sytuacje, w których użytkownicy witryny przechodzą między protokołem HTTP a HTTPS, a następnie kilka typowych scenariuszy i powiązany plik cookie SameSite są opisane poniżej.

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

  • W Chrome 86 włącz about://flags/#schemeful-same-site. Śledzenie postępów na stronie Stan Chrome .
  • W przeglądarce Firefox 79 ustaw opcję network.cookie.sameSite.schemeful na true za pomocą about:config Śledź postępy w Bugzilla .

Jeden z głównych powodów zmiany na opcję SameSite=Lax jako domyślną w usłudze miały chronić przed oszustwem żądań w wielu witrynach. (CSRF). Pamiętaj jednak: ale niezabezpieczony ruch HTTP wciąż stwarza możliwość atakującym sieci na modyfikować pliki cookie, które będą używane w bezpiecznej wersji HTTPS witryny witrynie. Utworzenie tej dodatkowej granicy między witrynami jeszcze większą obronę przed takimi atakami.

Typowe scenariusze obejmujące różne schematy

Przechodzenie między wersjami witryny opartymi na różnych schematach (np. połączenie z konta http://site.example do https://site.example) wcześniej zezwalałby Liczba plików cookie do wysłania: SameSite=Strict. Teraz jest traktowany jak żądanie z innej witryny co oznacza, że zostaną zablokowane pliki cookie SameSite=Strict.

Nawigacja między schematami aktywowana przez kliknięcie linku w niezabezpieczonej wersji HTTP witryny do bezpiecznej wersji HTTPS. SameSite=Strict zablokowane pliki cookie, SameSite=Lax i SameSite=None; Bezpieczne pliki cookie są dozwolone.
Przejście z HTTP do HTTPS w różnych schematach.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Zablokowano ⛔ Zablokowano
SameSite=Lax ✓ Dozwolone ✓ Dozwolone
SameSite=None;Secure ✓ Dozwolone ⛔ Zablokowano

Wczytuję zasoby podrzędne

Wprowadzone tutaj zmiany powinny być traktowane jako tymczasowa poprawka. przejść na pełny protokół HTTPS.

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

Wczytywanie na stronie zasobu podrzędnego innego schematu pozwoliłoby wcześniej Pliki cookie (SameSite=Strict lub SameSite=Lax) do wysłania lub ustawienia. A teraz jest traktowany w taki sam sposób, jak każdy inny zasób podrzędny zasobu innej firmy lub należący do innej witryny, oznacza, że zostaną zablokowane wszystkie pliki cookie SameSite=Strict lub SameSite=Lax.

Ponadto, nawet jeśli przeglądarka zezwala na zasoby z niezabezpieczonych schematów na gdy zostanie załadowana na bezpiecznej stronie, wszystkie pliki cookie będą blokowane w przypadku tych żądań, pliki cookie innych firm lub pochodzące z innych witryn wymagają parametru Secure.

Zasób podrzędny korzystający z różnych schematów powstały z zasobu z bezpiecznej wersji HTTPS witryny uwzględnionej w niezabezpieczonej wersji HTTP. pliki cookie SameSite=Strict i SameSite=Lax zostały zablokowane oraz SameSite=None; Bezpieczne pliki cookie są dozwolone.
Strona HTTP zawierająca zasób podrzędny z innymi schematami przez HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Zablokowano ⛔ Zablokowano
SameSite=Lax ⛔ Zablokowano ⛔ Zablokowano
SameSite=None;Secure ✓ Dozwolone ⛔ Zablokowano

OPUBLIKOWANIE formularza

Publikowanie między wersjami witryny bazującymi na różnych schematach dotychczas umożliwiałoby pliki cookie z ustawieniem SameSite=Lax lub SameSite=Strict do wysłania. A teraz traktowany jako POST pochodzący z innej witryny – można wysłać tylko SameSite=None plików cookie. Możesz występuje w takich witrynach, które domyślnie wyświetlają niezabezpieczoną wersję, ale podczas przesyłania danych logowania uaktualnij użytkowników do wersji zabezpieczonej formularza płatności.

Podobnie jak w przypadku zasobów podrzędnych, jeśli żądanie pochodzi z bezpiecznego adresu, np. HTTPS, do niezabezpieczone, np. HTTP, kontekst, a w przypadku tych żądań wszystkie pliki cookie będą blokowane ponieważ pliki cookie innych firm i pliki cookie pochodzące z innych witryn wymagają parametru Secure.

Przesłanie formularza z różnymi schematami, które pojawia się w wyniku przesłania formularza w niezabezpieczonej wersji HTTP witryny do bezpiecznej wersji HTTPS. pliki cookie SameSite=Strict i SameSite=Lax zostały zablokowane oraz SameSite=None; Bezpieczne pliki cookie są dozwolone.
Przesłanie formularza na różnych schematach 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 dla programistów i komunikatory są dostępne w Chrome i Firefoksie.

W Chrome 86 karta Problemy w Narzędzia deweloperskie uwzględnia problemy związane ze schematem Same-Site. Możesz zobaczyć wyróżnione te problemy dla Twojej witryny.

Problemy z nawigacją:

  • „Przejdź całkowicie na HTTPS, aby nadal wysyłać pliki cookie w tej samej witrynie żądania” – ostrzeżenie informujące o tym, że plik cookie zostanie zablokowany w przyszłej wersji; Chrome.
  • „Przeprowadź pełną migrację do HTTPS, aby pliki cookie były wysyłane w przypadku żądań z tej samej witryny” – z ostrzeżeniem, że plik cookie został zablokowany.

Problemy z ładowaniem zasobów podrzędnych:

  • „Przejdź całkowicie na HTTPS, aby nadal mieć możliwość wysyłania plików cookie do tej samej witryny zasoby podrzędne” lub „Przejdź całkowicie na HTTPS, aby nadal zezwalać na pliki cookie na zostanie ustawiony przez same-site subresources” – ostrzeżenia, że plik cookie zostanie zablokowane w przyszłej wersji Chrome.
  • „Przeprowadź migrację całkowicie do HTTPS, aby pliki cookie były wysyłane do zasobów podrzędnych tej samej witryny” lub „Przeprowadź pełną migrację do HTTPS, aby umożliwić ustawianie plików cookie przez tę samą witrynę subresources” – ostrzeżenia, że plik cookie został zablokowany. To ostatnie ostrzeżenie może również pojawić się podczas publikowania formularza.

Więcej informacji znajdziesz w artykule Wskazówki dotyczące testowania i debugowania w przypadku schematu Same-Site.

Z przeglądarki Firefox w wersji 79 z ustawieniem network.cookie.sameSite.schemeful ustawionym na true za pomocą about:config konsola wyświetli komunikat o problemach typu „Schemeful Same-Site”. W swojej witrynie możesz zobaczyć:

  • „Plik cookie cookie_name zostanie wkrótce potraktowany jako plik cookie z innej witryny w odniesieniu do http://site.example/, ponieważ schemat nie pasuje do wzorca”.
  • „Plik cookie cookie_name został potraktowany jako plik cookie z innej witryny http://site.example/, ponieważ schemat nie pasuje do wzorca”.

Najczęstsze pytania

Moja witryna jest już w pełni dostępna w protokole HTTPS. Dlaczego w Narzędziach deweloperskich w przeglądarce występują problemy?

Możliwe, że niektóre z Twoich linków i zasobów podrzędnych nadal wskazują niezabezpieczone Adresy URL.

Jednym ze sposobów rozwiązania tego problemu jest użycie protokołu HTTP rygorystyczne zasady bezpieczeństwa transportu (HSTS) i dyrektywę includeSubDomain. Z HSTS + includeSubDomain nawet jeśli któraś ze stron przypadkowo zawiera niezabezpieczony link, przeglądarka automatycznie korzysta z bezpiecznej wersji.

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

Choć zdecydowanie zalecamy całkowite uaktualnienie witryny do HTTPS ochrony użytkowników. Jeśli nie możesz tego zrobić samodzielnie, skontaktuj się z z Twoim dostawcą usług hostingowych. Jeśli jesteś właścicielem serwera, a następnie Let's Encrypt dostępne jest szereg narzędzi, zainstalować i skonfigurować certyfikat. Możesz również zbadać możliwość przeniesienia witryny za siecią CDN lub innym serwerem proxy, który może zapewnić połączenie HTTPS.

Jeśli to nadal nie jest możliwe, spróbuj złagodzić ustawienie zabezpieczenia SameSite pliki cookie, których dotyczy problem.

  • Jeśli blokowane są tylko pliki cookie (SameSite=Strict), możesz zmniejszyć liczbę plików cookie ochronę na stronie Lax.
  • W sytuacji, gdy zarówno pliki cookie Strict, jak i Lax są blokowane, są wysyłane na bezpieczny URL (lub ustawiane z niego), możesz zmniejszyć zabezpieczeń na poziomie None.
    • To obejście nie uda się, jeśli adres URL, na który wysyłasz pliki cookie (lub nie jest bezpieczne. Dzieje się tak, ponieważ SameSite=None wymaga parametru Secure w plikach cookie, co oznacza, że nie mogą one być wysyłane lub przez niezabezpieczone połączenie. W takim przypadku nie będzie można uzyskać dostępu do ten plik cookie, dopóki witryna nie zostanie uaktualniona do HTTPS.
    • Pamiętaj, że jest to sytuacja tymczasowa, ponieważ w przyszłości pliki cookie innych firm przestaną być zostały całkowicie wycofane.

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

Pliki cookie bez atrybutu SameSite są traktowane tak, jakby zostały określone SameSite=Lax i ten sam schemat działania odnosi się do tych plików cookie, co cóż. Pamiętaj, że nadal ma zastosowanie tymczasowy wyjątek od niebezpiecznych metod – zobacz łagodzenie skutków działań Lax i POST w Chromium SameSite Najczęstsze pytania.

Jaki ma to wpływ na standard WebSockets?

Połączenia WebSocket będą nadal uznawane za tę samą witrynę, jeśli są takie same bezpieczeństwa witryny.

Ta sama witryna:

  • wss:// przesiadka z: https://
  • ws:// przesiadka z: http://

Wiele witryn:

  • wss:// przesiadka z: http://
  • ws:// przesiadka z: https://

Fot. Julissa Capdevilla, włączono Odloty