Schemeryzująca tę samą witrynę

Definicja „tej samej witryny” ewoluuje i obejmuje teraz schemat adresu URL, więc linki między wersjami HTTP i HTTPS witryny są teraz traktowane jako żądania z innej witryny. Jeśli to możliwe, przejdź domyślnie na HTTPS, aby uniknąć problemów, lub przeczytaj dalszą część artykułu, aby dowiedzieć się, jakie wartości atrybutu SameSite są potrzebne.

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

Schemeful Same-Site modyfikuje definicję witryny (internetowej) z samej domeny rejestrowanej na schemat + domenę rejestrowaną. Więcej informacji i przykładów znajdziesz w artykule Omówienie pojęć "ta sama witryna" i "to samo pochodzenie".

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 nie masz jeszcze w pełni uaktualnionej witryny, to powinno być Twoim priorytetem. Jeśli jednak zdarzają się sytuacje, w których użytkownicy Twojej witryny przechodzą między HTTP a HTTPS, niektóre z tych typowych scenariuszy i powiązane z nimi zachowanie plików cookie SameSite opisujemy w dalszej części tego artykułu.

Możesz włączyć te zmiany do testowania w Chrome i Firefoxie.

  • W Chrome 86 włącz about://flags/#schemeful-same-site. Śledź postępy na stroniestanu Chrome.
  • W Firefoxie 79 ustaw network.cookie.sameSite.schemeful na true za pomocą about:config. Śledź postępy za pomocą zgłoszenia w Bugzilli.

Jednym z głównych powodów zmiany domyślnego ustawienia plików cookie na SameSite=Lax była ochrona przed atakami typu Cross-Site Request Forgery (CSRF). Niezabezpieczony ruch HTTP nadal stwarza jednak możliwość manipulowania plikami cookie przez osoby atakujące sieć, które będą następnie używane w zabezpieczonej wersji HTTPS witryny. Utworzenie dodatkowej granicy między schematami w różnych witrynach zapewnia dodatkową ochronę przed tymi atakami.

Typowe scenariusze obejmujące różne schematy

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

Nawigacja między schematami wywołana przez kliknięcie linku w niezabezpieczonej wersji witryny (HTTP) do jej bezpiecznej wersji (HTTPS). Pliki cookie SameSite=Strict są blokowane, a pliki cookie SameSite=Lax i SameSite=None; Secure są dozwolone.
Nawigacja między schematami z HTTP do HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Zablokowane ⛔ Zablokowane
SameSite=Lax ✓ Dozwolone ✓ Dozwolone
SameSite=None;Secure ✓ Dozwolone ⛔ Zablokowane

Wczytywanie zasobów podrzędnych

Wszelkie zmiany, które tu wprowadzisz, należy traktować tylko jako tymczasowe rozwiązanie, dopóki nie przejdziesz na pełny protokół HTTPS.

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

Wczytywanie zasobu podrzędnego obejmującego różne schematy na stronie umożliwiało wcześniej wysyłanie lub ustawianie plików cookie SameSite=Strict lub SameSite=Lax. Teraz jest to traktowane tak samo jak każdy inny zasób podrzędny innej firmy lub z innej witryny, co oznacza, że wszystkie pliki cookie SameSite=Strict lub SameSite=Lax będą blokowane.

Ponadto, nawet jeśli przeglądarka zezwala na wczytywanie zasobów z niezabezpieczonych schematów na zabezpieczonej stronie, wszystkie pliki cookie będą blokowane w tych żądaniach, ponieważ pliki cookie innych firm lub z innych witryn wymagają atrybutu Secure.

Podzasób z innego schematu, który jest wynikiem umieszczenia zasobu z bezpiecznej wersji HTTPS witryny w niezabezpieczonej wersji HTTP. Pliki cookie z ustawieniami SameSite=Strict i SameSite=Lax są blokowane, a pliki cookie z ustawieniem SameSite=None; Secure są dozwolone.
Strona HTTP zawierająca zasób podrzędny obejmujący różne schematy za pomocą HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Zablokowane ⛔ Zablokowane
SameSite=Lax ⛔ Zablokowane ⛔ Zablokowane
SameSite=None;Secure ✓ Dozwolone ⛔ Zablokowane

Wysyłanie formularza metodą POST

Wysyłanie danych między wersjami witryny obejmującymi różne schematy umożliwiało wcześniej wysyłanie plików cookie ustawionych za pomocą SameSite=Lax lub SameSite=Strict. Teraz jest to traktowane jako wysyłanie metodą POST z innej witryny – można wysyłać tylko pliki cookie SameSite=None. Ten scenariusz może wystąpić w witrynach, które domyślnie wyświetlają niezabezpieczoną wersję, ale po przesłaniu formularza logowania lub realizacji zakupu uaktualniają użytkowników do wersji zabezpieczonej.

Podobnie jak w przypadku zasobów podrzędnych, jeśli żądanie pochodzi z bezpiecznego kontekstu (np. HTTPS) do niezabezpieczonego kontekstu (np. HTTP), wszystkie pliki cookie będą blokowane w tych żądaniach, ponieważ pliki cookie innych firm lub z innych witryn wymagają atrybutu Secure.

Przesłanie formularza w ramach różnych schematów, które wynika z przesłania formularza z niezabezpieczonej wersji witryny HTTP do zabezpieczonej wersji HTTPS. Pliki cookie z ustawieniami SameSite=Strict i SameSite=Lax są blokowane, a pliki cookie z ustawieniem SameSite=None; Secure są dozwolone.
Przesyłanie formularza obejmującego różne schematy z HTTP do HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Zablokowane ⛔ Zablokowane
SameSite=Lax ⛔ Zablokowane ⛔ Zablokowane
SameSite=None;Secure ✓ Dozwolone ⛔ Zablokowane

Jak mogę przetestować swoją witrynę?

Narzędzia dla programistów i komunikaty są dostępne w Chrome i Firefoxie.

W Chrome 86 karta Problemy w Narzędziach deweloperskich będzie zawierać problemy z Schemeful Same-Site. W przypadku Twojej witryny mogą się pojawić te problemy:

Problemy z nawigacją:

  • „Aby nadal wysyłać pliki cookie w żądaniach z tej samej witryny, przeprowadź pełną migrację do HTTPS” – ostrzeżenie, że plik cookie zostanie zablokowany w przyszłej wersji Chrome.
  • „Aby wysyłać pliki cookie w żądaniach z tej samej witryny, przeprowadź pełną migrację do HTTPS” – ostrzeżenie, że plik cookie został zablokowany.

Problemy z wczytywaniem zasobów podrzędnych:

  • „Aby nadal wysyłać pliki cookie do zasobów podrzędnych z tej samej witryny, przeprowadź pełną migrację do HTTPS” lub „Aby nadal zezwalać zasobom podrzędnym z tej samej witryny na ustawianie plików cookie, przeprowadź pełną migrację do HTTPS” – ostrzeżenia, że plik cookie zostanie zablokowany w przyszłej wersji Chrome.
  • „Aby wysyłać pliki cookie do zasobów podrzędnych z tej samej witryny, przeprowadź pełną migrację do HTTPS” lub „Aby zezwalać zasobom podrzędnym z tej samej witryny na ustawianie plików cookie, przeprowadź pełną migrację do HTTPS” – ostrzeżenia, że plik cookie został zablokowany. To drugie ostrzeżenie może się też pojawić podczas wysyłania formularza metodą POST.

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

W Firefoxie 79, gdy network.cookie.sameSite.schemeful jest ustawione na true za pomocą about:config, w konsoli będzie się wyświetlać komunikat o problemach z Schemeful Same-Site. W swojej witrynie możesz zobaczyć te komunikaty:

  • „Plik cookie cookie_name wkrótce będzie traktowany jako plik cookie z innej witryny w przypadku http://site.example/, ponieważ schemat się nie zgadza”.
  • „Plik cookie cookie_name jest traktowany jako plik cookie z innej witryny w przypadku http://site.example/, ponieważ schemat się nie zgadza”.

Najczęstsze pytania

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

Możliwe, że niektóre linki i zasoby podrzędne nadal wskazują na niezabezpieczone adresy URL.

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

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

Zdecydowanie zalecamy przejście na HTTPS w całej witrynie, aby chronić użytkowników. Jeśli nie możesz tego zrobić samodzielnie, skontaktuj się z dostawcą hostingu, aby sprawdzić, czy oferuje taką opcję. Jeśli samodzielnie hostujesz witrynę, to Let's Encrypt udostępnia kilka narzędzi do instalowania i konfigurowania certyfikatu. Możesz też rozważyć przeniesienie witryny za CDN lub inny serwer proxy, który może zapewnić połączenie HTTPS.

Jeśli to nadal nie jest możliwe, spróbuj zmniejszyć ochronę SameSite w przypadku 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ą zarówno pliki cookie Strict, jak i Lax, a Twoje pliki cookie są wysyłane do (lub ustawiane z) bezpiecznego adresu URL, możesz obniżyć poziom ochrony do None.
    • To obejście nie zadziała , jeśli adres URL, do którego wysyłasz pliki cookie (lub z którego je ustawiasz), jest niezabezpieczony. Wynika to z tego, że SameSite=None wymaga atrybutu Secure w plikach cookie, co oznacza, że te pliki cookie nie mogą być wysyłane ani ustawiane przez niezabezpieczone połączenie. W takim przypadku nie będziesz mieć dostępu do tego pliku cookie, dopóki nie przejdziesz na HTTPS.
    • Pamiętaj, że jest to tylko rozwiązanie tymczasowe, ponieważ pliki cookie innych firm zostaną ostatecznie całkowicie wycofane.

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

Pliki cookie bez atrybutu SameSite są traktowane tak, jakby miały określony atrybut SameSite=Lax a to samo zachowanie w przypadku różnych schematów dotyczy też tych plików cookie. Pamiętaj, że tymczasowy wyjątek dotyczący niebezpiecznych metod nadal obowiązuje. Więcej informacji znajdziesz w sekcji Lax + POST mitigation w najczęstszych pytaniach dotyczących `SameSite` w Chromium SameSite FAQ .

Jak to wpływa na połączenia WebSocket?

Połączenia WebSocket będą nadal traktowane jako połączenia z tej samej witryny, jeśli mają ten sam poziom bezpieczeństwa co strona.

Ta sama witryna:

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

Inna witryna:

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