Sprawdzone metody dotyczące zasad dotyczących witryn odsyłających i witryn odsyłających

Na tej stronie przedstawiamy kilka sprawdzonych metod konfigurowania zasady dotyczącej stron odsyłających i używania strony odsyłającej w żądaniach przychodzących.

Podsumowanie

• Nieoczekiwany wyciek informacji z innych źródeł narusza prywatność użytkowników internetu. Pomóc może zasada dotycząca ochrony strony odsyłającej.
• Rozważ ustawienie zasady dotyczącej stron odsyłających na strict-origin-when-cross-origin. Zachowuje większość użyteczności strony odsyłającej, a jednocześnie niweluje ryzyko wycieku danych z innych domen.
• Nie używaj stron odsyłających do ochrony przed sfałszowaniem żądania z innej witryny (CSRF). Zamiast nich użyj tokenów CSRF i innych nagłówków jako dodatkowej warstwy zabezpieczeń.

Zasady dotyczące stron odsyłających i stron odsyłających 101

Żądania HTTP mogą zawierać opcjonalny nagłówek Referer, który wskazuje źródło lub adres URL strony internetowej, z której wysłano żądanie. Nagłówek Referrer-Policy określa, jakie dane są dostępne w nagłówku Referer.

W poniższym przykładzie nagłówek Referer zawiera pełny adres URL strony w witrynie site-one, z której wysłano żądanie.

Nagłówek Referer może występować w różnych typach żądań:

• Żądania nawigacji, gdy użytkownik kliknie link.
• Żądania zasobów podrzędnych, gdy przeglądarka wysyła żądania obrazów, elementów iframe, skryptów i innych zasobów potrzebnych stronie.

W przypadku elementów nawigacyjnych i elementów iframe możesz też uzyskać dostęp do tych danych za pomocą kodu JavaScript i elementu document.referrer.

Wartości parametru Referer mogą się wiele dowiedzieć. Usługa analityczna może na przykład użyć ich do ustalenia, że 50% użytkowników w witrynie site-two.example pochodzi z witryny social-network.example. Jednak gdy pełny adres URL, w tym ścieżka i ciąg zapytania, zostanie wysłany w Referer z różnych źródeł, może to zagrażać prywatności użytkowników i stwarzać zagrożenia:

Adresy URL od 1 do 5 zawierają informacje prywatne, a czasem poufne lub umożliwiające identyfikację. Dyskretne ujawnienie tych źródeł może zagrażać prywatności użytkowników internetu.

URL 6 to adres URL możliwości. Jeśli otrzyma go ktokolwiek inny niż zamierzony użytkownik, może przejąć kontrolę nad kontem użytkownika.

Aby ograniczyć udostępnianie danych stron odsyłających w przypadku żądań pochodzących z Twojej witryny, możesz ustawić zasadę dotyczącą stron odsyłających.

Jakie zasady są dostępne i czym się różnią?

Możesz wybrać jedną z 8 zasad. W zależności od zasady dane dostępne w nagłówku Referer (i document.referrer) mogą być:

• Brak danych (brak nagłówka Referer)
• Tylko parametr origin
• Pełny adres URL: źródło, ścieżka i ciąg zapytania

Niektóre zasady działają różnie w zależności od kontekstu: żądania z innych domen lub z tej samej domeny, od tego, czy miejsce docelowe żądania jest tak samo bezpieczne jak źródło treści, czy też jedno i drugie. Pomaga to ograniczyć ilość informacji udostępnianych między źródłami lub mniej bezpiecznymi źródłami przy jednoczesnym zachowaniu bogactwa strony odsyłającej we własnej witrynie.

W tabeli poniżej pokazujemy, jak zasady dotyczące stron odsyłających ograniczają dostęp do danych adresu URL z nagłówka strony odsyłającej i elementu document.referrer:

Zakres zasady	Nazwa zasady	Strona odsyłająca: brak danych	Strona odsyłająca: tylko źródło	Strona odsyłająca: pełny adres URL
Nie uwzględnia kontekstu żądania	no-referrer	sprawdź
	origin		sprawdź
	unsafe-url			sprawdź
Bezpieczeństwo	strict-origin	Żądanie z HTTPS do HTTP	Żądanie z HTTPS do HTTPS lub z HTTP do HTTP
	no-referrer-when-downgrade	Żądanie z HTTPS do HTTP		Żądanie z HTTPS do HTTPS lub z HTTP do HTTP
Ochrona prywatności	origin-when-cross-origin		Żądanie z innej domeny	Żądanie z tej samej domeny
	same-origin	Żądanie z innej domeny		Żądanie z tej samej domeny
Ochrona prywatności i bezpieczeństwa	strict-origin-when-cross-origin	Żądanie z HTTPS do HTTP	Żądanie między domenami z HTTPS do HTTPS lub z HTTP do HTTP	Żądanie z tej samej domeny

MDN zawiera pełną listę zasad i przykładów zachowań.

Oto kilka kwestii, o których należy pamiętać podczas konfigurowania zasad dotyczących stron odsyłających:

• Wszystkie zasady uwzględniające ten schemat (HTTPS lub HTTP) (strict-origin, no-referrer-when-downgrade i strict-origin-when-cross-origin) traktują żądania z jednego źródła HTTP do innego źródła HTTP tak samo jak żądania ze źródła HTTPS do innego źródła HTTPS, mimo że protokół HTTP jest mniej bezpieczny. Dzieje się tak dlatego, że w przypadku tych zasad liczy się to, czy nastąpi zmiana zabezpieczeń, czyli czy żądanie może ujawnić dane z zaszyfrowanego źródła niezaszyfrowanemu, tak jak w przypadku żądań HTTPS → HTTP. Żądanie HTTP → HTTP jest całkowicie niezaszyfrowane i nie można przejść na wersję standardową.
• Jeśli żądanie ma źródło same-origin, oznacza to, że schemat (HTTPS lub HTTP) jest taki sam, więc zabezpieczenia nie zostaną obniżone.

Domyślne zasady dotyczące stron odsyłających w przeglądarkach

Stan na październik 2021 r.

Jeśli nie ustawisz żadnej zasady dotyczącej stron odsyłających, przeglądarka użyje zasady domyślnej.

Sprawdzone metody ustawiania zasad dotyczących stron odsyłających

Zasady dotyczące stron odsyłających można ustawić w witrynie na różne sposoby:

• Jako nagłówek HTTP
• W kodzie HTML
• Z JavaScriptu na poziomie żądania

Możesz ustawić różne zasady dla różnych stron, żądań lub elementów.

Nagłówek HTTP i element meta działają na poziomie strony. Priorytet określania efektywnej zasady danego elementu jest następujący:

1. Zasada na poziomie elementu
2. Zasady na poziomie strony
3. Ustawienie domyślne przeglądarki

Przykład:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

Żądanie obrazu jest wysyłane za pomocą zasady no-referrer-when-downgrade, a wszystkie inne żądania zasobów podrzędnych z tej strony są zgodne z zasadą strict-origin-when-cross-origin.

Jak wyświetlić zasady dotyczące stron odsyłających?

Strona securityheaders.com pozwala łatwo określić, których zasad używa konkretna witryna lub strona.

Aby zobaczyć zasady dotyczące strony odsyłającej użyte w przypadku konkretnego żądania, możesz też użyć narzędzi dla programistów w przeglądarkach Chrome, Edge lub Firefox. W momencie tworzenia tego tekstu Safari nie wyświetla nagłówka Referrer-Policy, ale wyświetla wysłanego Referer.

Którą zasadę należy skonfigurować w przypadku swojej witryny?

Zdecydowanie zalecamy jawne ustawienie zasady chroniącej prywatność, np. strict-origin-when-cross-origin (lub bardziej rygorystycznej).

Dlaczego „wyraźnie”?

Jeśli nie skonfigurujesz zasad dotyczących stron odsyłających, będą używane domyślne zasady przeglądarki – witryny często ustawiają je na wartość domyślną przeglądarki. Nie jest to jednak idealne, ponieważ:

• Różne przeglądarki mają różne zasady domyślne, więc jeśli skorzystasz z domyślnych ustawień przeglądarki, Twoja witryna nie będzie działać w przewidywalny sposób.
• Przeglądarki przyjmują bardziej rygorystyczne ustawienia domyślne, np. strict-origin-when-cross-origin, i mechanizmy takie jak przycinanie stron odsyłających w przypadku żądań z innych domen. Wyraźne wyrażenie zgody na zasady chroniące prywatność przed zmianą ustawień domyślnych przeglądarki daje Ci kontrolę i ułatwia Ci przeprowadzanie testów według własnego uznania.

Dlaczego strict-origin-when-cross-origin (lub bardziej rygorystycznie)?

Potrzebujesz zasad, które są bezpieczne i zapewniają ochronę prywatności oraz są przydatne. Co to znaczy „przydatny” zależy od tego, czego oczekujesz od strony odsyłającej:

• Bezpieczeństwo: jeśli Twoja witryna korzysta z protokołu HTTPS (jeśli nie, ustaw go jako priorytet), aby zapobiec wyciekom adresów URL w żądaniach innych niż HTTPS. Każdy w sieci może to zobaczyć, więc wyciek danych naraża użytkowników na ataki pośrednie. Zasady no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer i strict-origin rozwiązują ten problem.
• Ochrona prywatności: w przypadku żądań dotyczących innych domen no-referrer-when-downgrade udostępnia pełny adres URL, co może powodować problemy dotyczące prywatności. strict-origin-when-cross-origin i strict-origin udostępniają tylko dane o pochodzeniu, a no-referrer niczego nie udostępnia. Dzięki temu możesz korzystać z opcji strict-origin-when-cross-origin, strict-origin i no-referrer, które zwiększają ochronę prywatności.
• Przydatne: no-referrer i strict-origin nigdy nie udostępniają pełnego adresu URL, nawet w przypadku żądań z tego samego źródła. Jeśli potrzebujesz pełnego adresu URL, lepszą opcją jest strict-origin-when-cross-origin.

Wszystko to oznacza, że strict-origin-when-cross-origin to zwykle rozsądna opcja.

Przykład: konfigurowanie zasady strict-origin-when-cross-origin

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

Lub po stronie serwera, na przykład w Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Co zrobić, jeśli strict-origin-when-cross-origin (lub bardziej rygorystycznie) nie uwzględnia niektórych przypadków użycia?

W takim przypadku zastosuj progresywne podejście: ustaw dla swojej witryny zasadę ochronną, np. strict-origin-when-cross-origin, i w razie potrzeby bardziej restrykcyjną zasadę dotyczącą określonych żądań lub elementów HTML.

Przykład: zasady na poziomie elementu

index.html:

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

Safari/WebKit może ograniczać nagłówek document.referrer lub Referer w przypadku żądań z innej witryny. Zobacz szczegóły.

Przykład: zasada na poziomie żądania

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

Co jeszcze warto wziąć pod uwagę?

Zasady powinny zależeć od Twojej witryny i przypadków użycia określonych przez Ciebie, Twój zespół i Twoją firmę. Jeśli niektóre adresy URL zawierają dane umożliwiające identyfikację lub dane wrażliwe, ustaw zasadę ochronną.

Sprawdzone metody dotyczące żądań przychodzących

Poniżej znajdziesz wskazówki, co zrobić, gdy Twoja witryna korzysta z adresu URL strony odsyłającej w przypadku żądań przychodzących.

Ochrona danych użytkowników

Referer może zawierać dane prywatne, osobowe lub informacje umożliwiające identyfikację, więc pamiętaj, by traktować je jako poufne.

Przychodzące strony odsyłające mogą zmienić {referer-can-change}

Korzystanie z elementu odsyłającego z nachodzących żądań z innych domen ma kilka ograniczeń:

• Jeśli nie masz kontroli nad implementacją nadawcy żądań, nie możesz wyciągać założeń dotyczących otrzymywanego nagłówka Referer (i document.referrer). Nadawca żądań może w każdej chwili przejść na zasadę no-referrer lub bardziej ogólnie na bardziej rygorystyczną niż ta stosowana wcześniej. Oznacza to, że otrzymujesz mniej danych z usługi Referer niż wcześniej.
• Przeglądarki coraz częściej używają domyślnie zasady dotyczącej stron odsyłających strict-origin-when-cross-origin. Oznacza to, że w przychodzących żądaniach z innych domen możesz teraz otrzymywać tylko źródło zamiast pełnego adresu URL strony odsyłającej, jeśli witryna nadawcy nie ma ustawionych zasad.
• Przeglądarki mogą zmienić sposób zarządzania stroną Referer. Na przykład niektórzy deweloperzy przeglądarek mogą zdecydować się na ciągłe przycinanie stron odsyłających do źródeł w żądaniach zasobów podrzędnych z innych domen, aby chronić prywatność użytkowników.
• Nagłówek Referer (i document.referrer) może zawierać więcej danych, niż potrzebujesz. Może on na przykład mieć pełny adres URL, jeśli chcesz wiedzieć tylko, czy żądanie pochodzi z innych domen.

Alternatywy dla: Referer

Być może warto rozważyć inne rozwiązania, jeśli:

• Zasadnicza funkcja witryny korzysta z adresu URL strony odsyłającej w przypadku przychodzących żądań z innych domen.
• Twoja witryna nie otrzymuje już tej części adresu URL strony odsyłającej, której potrzebuje w żądaniu z innych domen. Dzieje się tak, gdy emiter żądań zmieni swoją zasadę lub gdy nie ustawisz żadnej zasady i zmieni się domyślne zasady przeglądarki (jak w Chrome 85).

Aby określić alternatywy, sprawdź najpierw, z której części strony odsyłającej korzystasz.

Jeśli potrzebujesz tylko punktu początkowego

• Jeśli używasz strony odsyłającej w skrypcie, który ma dostęp najwyższego poziomu do strony, zamiast tego możesz użyć window.location.origin.
• Jeśli są dostępne, w nagłówkach takich jak Origin i Sec-Fetch-Site znajdziesz parametr Origin lub opisz, czy żądanie pochodzi z innych domen, co może być dokładnie tym, czego potrzebujesz.

Jeśli potrzebujesz innych elementów adresu URL (ścieżki, parametrów zapytania...)

• Parametry żądania mogą być przydatne w Twoim przypadku użycia, dzięki czemu nie musisz analizować witryny odsyłającej.
• Jeśli używasz strony odsyłającej w skrypcie, który ma dostęp najwyższego poziomu do strony, alternatywą może być window.location.pathname. Wyodrębnianie tylko sekcji ścieżki adresu URL i przekazywanie jej jako argumentu, aby nie były przekazywane żadne potencjalnie poufne informacje zawarte w parametrach adresu URL.

Jeśli nie możesz zastosować tych rozwiązań:

• Sprawdź, czy możesz zmienić swoje systemy tak, aby nadawcy żądań (np. site-one.example) wyraźnie określali potrzebne informacje w jakiejś konfiguracji.
  • Za: bardziej widoczne, bardziej chroniące prywatność użytkowników site-one.example i bardziej dostosowane do przyszłości.
  • Wada: potencjalnie więcej pracy po Twojej stronie lub dla użytkowników systemu.
• Sprawdź, czy witryna wysyłająca żądania może zgodzić się na ustawienie zasady dotyczącej stron odsyłających na element lub na żądanie na poziomie no-referrer-when-downgrade.
  • Wady: potencjalnie mniej chroni prywatność użytkowników site-one.example i nie jest obsługiwane we wszystkich przeglądarkach.

Ochrona przed sfałszowaniem żądania z innej witryny (CSRF)

Emit żądania może zawsze zdecydować, aby nie wysyłać strony odsyłającej, ustawiając zasadę no-referrer, a szkodliwy podmiot może nawet podszyć się pod stronę odsyłającą.

Używaj tokenów CSRF jako głównego zabezpieczenia. Aby uzyskać dodatkową ochronę, użyj SameSite i zamiast Referer używaj nagłówków takich jak Origin (dostępny w żądaniach POST i CORS) i Sec-Fetch-Site, jeśli jest dostępny.

Dziennik i debugowanie

Zadbaj o ochronę danych osobowych i poufnych użytkowników, które mogą się znajdować w Referer.

Jeśli używasz tylko źródła, sprawdź, czy zamiast niego możesz użyć nagłówka Origin. Dzięki temu możesz uzyskać informacje potrzebne do debugowania w prostszy sposób, bez konieczności analizowania strony odsyłającej.

Płatności

Dostawcy usług płatniczych mogą korzystać z nagłówka Referer przychodzących żądań w celu kontroli bezpieczeństwa.

Na przykład:

• Użytkownik klika przycisk Kup w witrynie online-shop.example/cart/checkout.
• online-shop.example przekierowuje na stronę payment-provider.example, która zarządza transakcją.
• payment-provider.example porównuje wartość Referer w tym żądaniu z listą dozwolonych wartości Referer skonfigurowanych przez sprzedawców. Jeśli do żadnego wpisu na liście nie pasuje żaden element, payment-provider.example odrzuca żądanie. Jeśli kod pasuje, użytkownik może przejść do transakcji.

Sprawdzone metody kontroli zabezpieczeń przepływu płatności

Jako dostawca usług płatniczych możesz używać Referer jako podstawowego potwierdzenia przed niektórymi atakami. Sam nagłówek Referer nie jest jednak rzetelną podstawą do sprawdzenia. Witryna, która wysłała prośbę, niezależnie od tego, czy jest legalnym sprzedawcą, może ustawić zasadę no-referrer, która sprawi, że informacje z Referer będą niedostępne dla dostawcy usług płatniczych.

Zapoznanie się z Referer może pomóc dostawcom usług płatniczych złapać naiwnych atakujących, którzy nie ustawili zasady no-referrer. Jeśli podczas pierwszej weryfikacji użyjesz karty Referer:

• Referer nie musi być dostępny zawsze. Jeśli jest, sprawdź go pod kątem minimalnej ilości danych, które może zawierać, czyli źródła.
  • Podczas konfigurowania listy dozwolonych wartości Referer pamiętaj, aby uwzględnić tylko źródło, a nie ścieżkę.
  • Na przykład dozwolone wartości Referer w polu online-shop.example powinny wynosić online-shop.example, a nie online-shop.example/cart/checkout. Jeśli nie oczekujesz żadnej wartości Referer lub wartości Referer, która będzie tylko źródłem witryny wysyłającej żądanie, unikniesz błędów, które mogą wynikać z oszacowań dotyczących elementu Referrer-Policy sprzedawcy.
• Jeśli brakuje Referer lub jest on dostępny, a podstawowa kontrola źródła Referer się powiodła, możesz przejść do innej, bardziej niezawodnej metody weryfikacji.

Aby dokładniej weryfikować płatności, zezwól osobie zgłaszającej zaszyfrowanie parametrów żądania unikalnym kluczem. Dostawcy usług płatniczych mogą wtedy obliczyć ten sam hasz po Twojej stronie i zaakceptować żądanie tylko wtedy, gdy odpowiada to Twoim obliczeniom.

Co się stanie z Referer, gdy witryna sprzedawcy HTTP bez zasady dotyczącej stron odsyłających przekierowuje do dostawcy usług płatniczych HTTPS?

W żądaniu wysyłanym do dostawcy usług płatniczych HTTPS nie wyświetla się pole Referer, ponieważ większość przeglądarek domyślnie używa strict-origin-when-cross-origin lub no-referrer-when-downgrade, gdy witryna nie ma ustawionych zasad. Zmiana zasady Chrome na nową zasadę domyślną nie zmieni tego działania.

Podsumowanie

Zasady dotyczące stron odsyłających to świetny sposób na zapewnienie użytkownikom większej prywatności.

Więcej informacji o różnych metodach ochrony użytkowników znajdziesz w kolekcji Bezpieczeństwo

Zasoby

• Interpretacja definicji „sama witryna” i „ta sama witryna”
• Nowy nagłówek zabezpieczeń: Zasady dotyczące stron odsyłających (2017)
• Zasada odsyłająca w MDN
• Nagłówek strony odsyłającej: Kwestie związane z prywatnością i bezpieczeństwem w MDN
• Zmiana w Chrome: zaimplementuj intencję Blink
• Zmiana w Chrome: przycisk „Mrugnięcie” w celu wysłania
• Zmiana w Chrome: wpis stanu
• Zmiana dotycząca Chrome: post na blogu w wersji beta 85
• Strona odsyłająca przycina wątek z GitHuba: co robią różne przeglądarki
• Specyfikacja zasad dotyczących stron odsyłających

Dziękujemy za publikowanie treści i przekazywanie opinii wszystkim weryfikatorom – zwłaszcza Kaustubha Govind, Davida Van Cleve, Mike'a Westa, Sama Duttona, Rowan Merewood, Jxck i Kayce Basques.