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
istrict-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.
Przeglądający | Domyślny Referrer-Policy / działanie |
---|---|
Chrome |
Wartość domyślna to strict-origin-when-cross-origin .
|
Firefox |
Wartość domyślna to strict-origin-when-cross-origin .Od wersji 93 w przypadku użytkowników korzystających ze ścisłej ochrony przed śledzeniem i przeglądania prywatnego mniej restrykcyjne zasady dotyczące stron odsyłających ( no-referrer-when-downgrade , origin-when-cross-origin i unsafe-url ) są ignorowane w przypadku żądań z innych witryn, co oznacza, że w przypadku tych żądań strona odsyłająca jest zawsze skracana, niezależnie od zasad danej witryny.
|
Edge |
Wartość domyślna to strict-origin-when-cross-origin .
|
Safari |
Wartość domyślna jest podobna do strict-origin-when-cross-origin , ale występują pewne różnice. Więcej informacji znajdziesz w artykule
Zapobieganie śledzeniu za pomocą funkcji zapobiegania śledzeniu.
|
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:
- Zasada na poziomie elementu
- Zasady na poziomie strony
- 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
istrict-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
istrict-origin
udostępniają tylko dane o pochodzeniu, ano-referrer
niczego nie udostępnia. Dzięki temu możesz korzystać z opcjistrict-origin-when-cross-origin
,strict-origin
ino-referrer
, które zwiększają ochronę prywatności. - Przydatne:
no-referrer
istrict-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ą jeststrict-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
(idocument.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ługiReferer
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
(idocument.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
iSec-Fetch-Site
znajdziesz parametrOrigin
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.
- Za: bardziej widoczne, bardziej chroniące prywatność użytkowników
- 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.
- Wady: potencjalnie mniej chroni prywatność użytkowników
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ściReferer
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 poluonline-shop.example
powinny wynosićonline-shop.example
, a nieonline-shop.example/cart/checkout
. Jeśli nie oczekujesz żadnej wartościReferer
lub wartościReferer
, 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 elementuReferrer-Policy
sprzedawcy.
- Podczas konfigurowania listy dozwolonych wartości
- Jeśli brakuje
Referer
lub jest on dostępny, a podstawowa kontrola źródłaReferer
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.