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

Maud Nalpas

Na tej stronie znajdziesz sprawdzone metody ustawiania nagłówka Referrer-Policy i używania nagłówka Referrer w przychodzących żądaniach.

Podsumowanie

  • Nieoczekiwany wyciek informacji między domenami narusza prywatność użytkowników internetu. Może w tym pomóc zasada dotycząca stron odsyłających, która chroni dane.
  • Rozważ ustawienie zasady dotyczącej stron odsyłających na strict-origin-when-cross-origin. Zachowuje większość przydatnych informacji o stronie odsyłającej, jednocześnie zmniejszając ryzyko wycieku danych między różnymi domenami.
  • Nie używaj stron odsyłających do ochrony przed fałszowaniem żądań z innej witryny (CSRF). Zamiast tego używaj tokenów CSRF i innych nagłówków jako dodatkowej warstwy zabezpieczeń.

Podstawowe informacje o nagłówkach Referer i Referrer-Policy

Żą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ą udostępniane w nagłówku Referer.

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

Żądanie HTTP zawierające nagłówek Referer.
Żądanie HTTP z nagłówkiem Referer.

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 żąda obrazów, elementów iframe, skryptów i innych zasobów, których potrzebuje strona;

W przypadku nawigacji i elementów iframe możesz też uzyskać dostęp do tych danych za pomocą kodu JavaScript, używając document.referrer.

Wartości Referer mogą Ci wiele powiedzieć. Na przykład usługa analityczna może ich użyć, aby określić, że 50% użytkowników odwiedzających witrynę site-two.example pochodzi z witryny social-network.example. Jednak gdy pełny adres URL, w tym ścieżka i ciąg zapytania, jest wysyłany w nagłówku Referer między domenami, może to stanowić zagrożenie dla prywatności użytkownika i bezpieczeństwa:

Adresy URL ze ścieżkami, które są mapowane na różne zagrożenia związane z prywatnością i bezpieczeństwem.
Używanie pełnego adresu URL może mieć wpływ na prywatność i bezpieczeństwo użytkowników.

Adresy URL od 1 do 5 zawierają informacje prywatne, a czasami informacje poufne lub umożliwiające identyfikację. Wyciek tych danych między źródłami może naruszyć prywatność użytkowników internetu.

URL 6 to adres URL funkcji. Jeśli otrzyma go ktoś inny niż dany użytkownik, nieuczciwy podmiot może przejąć kontrolę nad kontem tego użytkownika.

Aby ograniczyć dane o stronie odsyłającej, które są udostępniane w przypadku żądań z Twojej witryny, możesz ustawić zasady dotyczące strony odsyłającej.

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

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

  • Brak danych (brak nagłówka Referer)
  • Tylko punkt początkowy
  • Pełny adres URL: źródło, ścieżka i ciąg zapytania.
Dane, które mogą być zawarte w nagłówku Referer i elemencie document.referrer.
Przykłady danych Referer.

Niektóre zasady są zaprojektowane tak, aby działały inaczej w zależności od kontekstu: żądania współdzielenia lub żądania tego samego pochodzenia, tego, czy miejsce docelowe żądania jest tak samo bezpieczne jak źródło, lub obu tych czynników. Jest to przydatne, gdy chcesz ograniczyć ilość informacji udostępnianych między różnymi źródłami lub mniej bezpiecznym źródłom, zachowując jednocześnie bogactwo informacji o stronie odsyłającej w obrębie własnej witryny.

W tabeli poniżej pokazujemy, jak zasady dotyczące stron odsyłających ograniczają dane URL dostępne w nagłówku Referer i document.referrer:

Zakres zasady Nazwa zasady Referer: No data (Odsyłacz: brak danych) Referer: Origin only (Tylko źródło) Strona odsyłająca: pełny adres URL
Nie uwzględnia kontekstu prośby no-referrer sprawdź
origin sprawdź
unsafe-url sprawdź
Zorientowane na 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
Zapewnianie ochrony prywatności origin-when-cross-origin Żądanie z innej domeny Żądanie z tego samego źródła
same-origin Żądanie z innej domeny Żądanie z tego samego źródła
Skupienie na prywatności i bezpieczeństwie strict-origin-when-cross-origin Żądanie z HTTPS do HTTP Żądanie współdzielenia
z HTTPS do HTTPS
lub z HTTP do HTTP		 Żądanie z tego samego źródła

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

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

  • Wszystkie zasady, które uwzględniają 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 z jednego źródła HTTPS do innego źródła HTTPS, mimo że protokół HTTP jest mniej bezpieczny. Dzieje się tak, ponieważ w przypadku tych zasad liczy się to, czy następuje obniżenie poziomu zabezpieczeń, czyli czy żądanie może ujawnić dane z zaszyfrowanego źródła niezaszyfrowanemu, jak w przypadku żądań HTTPS → HTTP. Żądanie HTTP → HTTP jest całkowicie niezaszyfrowane, więc nie dochodzi do obniżenia poziomu zabezpieczeń.
  • Jeśli żądanie pochodzi z tego samego źródła, oznacza to, że schemat (HTTPS lub HTTP) jest taki sam, więc nie dochodzi do obniżenia poziomu zabezpieczeń.

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

Dane z października 2021 r.

Jeśli nie ustawiono żadnej zasady dotyczącej strony odsyłającej, przeglądarka używa zasady domyślnej.

Przeglądarka Domyślna karta Referrer-Policy / Zachowanie
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. Oznacza to, że strona odsyłająca jest zawsze przycinana w przypadku żądań z innych witryn, niezależnie od zasad witryny.
Edge Wartość domyślna to strict-origin-when-cross-origin.
Safari Domyślna wartość jest podobna do strict-origin-when-cross-origin, ale występują pewne różnice. Więcej informacji znajdziesz w artykule Zapobieganie śledzeniu przez funkcję zapobiegania śledzeniu.

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

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

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

Nagłówek HTTP i element meta są na poziomie strony. Kolejność priorytetów przy określaniu obowiązującej zasady elementu jest następująca:

  1. Zasady na poziomie elementu
  2. Zasady na poziomie strony
  3. Domyślny motyw przeglądarki

Przykład:

index.html:

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

Obraz jest żądany zgodnie z zasadami no-referrer-when-downgrade, a wszystkie inne żądania zasobów podrzędnych z tej strony są zgodne z zasadami strict-origin-when-cross-origin.

Jak sprawdzić zasady dotyczące strony odsyłającej?

securityheaders.com jest przydatna do określania, jakich zasad używa konkretna witryna lub strona.

Możesz też użyć narzędzi dla programistów w Chrome, Edge lub Firefoksie, aby sprawdzić zasady dotyczące stron odsyłających używane w przypadku konkretnego żądania. W momencie pisania tego artykułu Safari nie wyświetla nagłówka Referrer-Policy, ale pokazuje wysłany nagłówek Referer.

Zrzut ekranu panelu Sieć w Narzędziach deweloperskich w Chrome, na którym widać nagłówki Referer i Referrer-Policy.
Panel Sieć w Narzędziach deweloperskich w Chrome z wybranym żądaniem.

Którą zasadę należy ustawić dla witryny?

Zdecydowanie zalecamy jawne ustawienie zasady zwiększającej prywatność, takiej jak strict-origin-when-cross-origin (lub bardziej rygorystycznej).

Dlaczego „wyraźnie”?

Jeśli nie ustawisz zasady dotyczącej strony odsyłającej, zostanie użyta domyślna zasada przeglądarki. Witryny często korzystają z domyślnych ustawień przeglądarki. Nie jest to jednak idealne rozwiązanie, ponieważ:

  • Różne przeglądarki mają różne zasady domyślne, więc jeśli polegasz na ustawieniach domyślnych przeglądarki, Twoja witryna nie będzie działać w przewidywalny sposób w różnych przeglądarkach.
  • Przeglądarki wprowadzają bardziej rygorystyczne ustawienia domyślne, takie jak strict-origin-when-cross-origin, oraz mechanizmy takie jak przycinanie strony odsyłającej w przypadku żądań współdzielenia. Wyraźne zaakceptowanie zasad zwiększających ochronę prywatności przed zmianą domyślnych ustawień przeglądarki daje Ci kontrolę i pomaga przeprowadzać testy według własnego uznania.

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

Potrzebujesz zasad, które są bezpieczne, zwiększają prywatność i są przydatne. To, co jest „przydatne”, zależy od tego, czego oczekujesz od strony odsyłającej:

  • Bezpieczeństwo: jeśli Twoja witryna używa protokołu HTTPS (jeśli nie, potraktuj to priorytetowo), nie chcesz, aby adresy URL Twojej witryny wyciekały w żądaniach innych niż HTTPS. Każdy użytkownik sieci może je zobaczyć, więc wycieki mogą narazić użytkowników na ataki typu „człowiek pośrodku”. Ten problem rozwiązują zasady no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer i strict-origin.
  • Zwiększona ochrona prywatności: w przypadku żądania współdzielenia no-referrer-when-downgrade udostępnia pełny adres URL, co może powodować problemy z prywatnością. strict-origin-when-cross-origin i strict-origin udostępniają tylko źródło, a no-referrer nie udostępnia niczego. W takiej sytuacji opcjami zwiększającymi prywatność są strict-origin-when-cross-origin, strict-origin i no-referrer.
  • 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, lepszym rozwiązaniem jest strict-origin-when-cross-origin.

Wszystko to oznacza, że strict-origin-when-cross-origin jest ogólnie rozsądnym wyborem.

Przykład: ustawianie 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 rygorystyczne ustawienie) nie obejmuje wszystkich przypadków użycia?

W takim przypadku zastosuj podejście progresywne: ustaw dla witryny zasadę ochronną, np. strict-origin-when-cross-origin, a w razie potrzeby bardziej liberalną zasadę dla konkretnych żądań lub elementów HTML.

Przykład: zasada 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 należy wziąć pod uwagę?

Zasady powinny zależeć od witryny i przypadków użycia, które określisz Ty, Twój zespół i Twoja firma. Jeśli niektóre adresy URL zawierają dane umożliwiające identyfikację lub dane wrażliwe, ustaw zasadę ochrony.

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

Oto kilka wskazówek, co zrobić, jeśli Twoja witryna używa adresu URL strony odsyłającej w przypadku żądań przychodzących.

Ochrona danych użytkowników

Referer może zawierać prywatne, osobiste lub umożliwiające identyfikację dane, więc traktuj go odpowiednio.

Przychodzące strony odsyłające mogą się zmieniać {referer-can-change}

Używanie strony odsyłającej z przychodzących żądań współdzielenia ma kilka ograniczeń:

  • Jeśli nie masz kontroli nad implementacją emitera żądań, nie możesz zakładać, że otrzymasz nagłówek Referer (i document.referrer). Emitent żądania może w każdej chwili zdecydować się na przejście na zasadę no-referrer lub ogólnie na bardziej rygorystyczną zasadę niż ta , której używał wcześniej. Oznacza to, że otrzymujesz mniej danych z Referer niż wcześniej.
  • Przeglądarki coraz częściej domyślnie używają nagłówka Referrer-Policy strict-origin-when-cross-origin. Oznacza to, że w przychodzących żądaniach współdzielenia możesz teraz otrzymywać tylko źródło, a nie pełny adres URL strony odsyłającej, jeśli witryna nadawcy nie ma skonfigurowanych zasad.
  • Przeglądarki mogą zmienić sposób zarządzania Referer. Na przykład niektórzy deweloperzy przeglądarek mogą zdecydować, że w celu ochrony prywatności użytkowników zawsze będą przycinać adresy URL stron odsyłających do źródeł w żądaniach zasobów podrzędnych współdzielenia.
  • Nagłówek Referer (i document.referrer) może zawierać więcej danych, niż potrzebujesz. Może na przykład zawierać pełny adres URL, gdy chcesz tylko wiedzieć, czy żądanie jest typu współdzielenie.

Alternatywy dla: Referer

Warto rozważyć alternatywne rozwiązania, jeśli:

  • Istotna funkcja Twojej witryny używa adresu URL strony odsyłającej przychodzących żądań współdzielenia.
  • Twoja witryna nie otrzymuje już części adresu URL strony odsyłającej, której potrzebuje w żądaniu współdzielenia. Dzieje się tak, gdy nadawca żądania zmieni swoje zasady lub gdy nie ma ustawionych zasad, a domyślne zasady przeglądarki uległy zmianie (jak w Chrome 85).

Aby określić alternatywne rozwiązania, najpierw przeanalizuj, której części adresu URL strony odsyłającej używasz.

Jeśli potrzebujesz tylko punktu początkowego

  • Jeśli używasz strony odsyłającej w skrypcie, który ma dostęp do strony na najwyższym poziomie, alternatywą jest window.location.origin.
  • Jeśli są dostępne, nagłówki takie jak Origin i Sec-Fetch-Site podają Origin lub opisują, czy żądanie jest współdzielone, co może być dokładnie tym, czego potrzebujesz.

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

  • Parametry żądania mogą rozwiązać Twój problem, co pozwoli Ci uniknąć analizowania strony odsyłającej.
  • Jeśli używasz strony odsyłającej w skrypcie, który ma dostęp do strony na najwyższym poziomie, alternatywą może być window.location.pathname. Wyodrębnij tylko sekcję ścieżki adresu URL i przekaż ją jako argument, aby nie przekazywać żadnych potencjalnie poufnych informacji w parametrach adresu URL.

Jeśli nie możesz skorzystać z tych alternatywnych rozwiązań:

  • Sprawdź, czy możesz zmienić systemy tak, aby oczekiwały, że nadawca żądania (np. site-one.example) wyraźnie ustawi potrzebne informacje w jakiejś konfiguracji.
    • Zalety: bardziej jednoznaczne, lepiej chroniące prywatność użytkowników site-one.example, bardziej przyszłościowe.
    • Wada: potencjalnie więcej pracy dla Ciebie lub użytkowników Twojego systemu.
  • Sprawdź, czy witryna, która wysyła żądania, może zgodzić się na ustawienie zasady Referrer-Policy dla elementu lub żądania na no-referrer-when-downgrade.
    • Wada: potencjalnie mniejsza ochrona prywatności użytkowników site-one.example, potencjalny brak obsługi w niektórych przeglądarkach.

Ochrona przed fałszowaniem żądań z innych witryn (CSRF)

Nadawca żądania może zawsze zdecydować, że nie będzie wysyłać strony odsyłającej, ustawiając zasadę no-referrer, a nieuczciwy podmiot może nawet sfałszować stronę odsyłającą.

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

Logowanie i debugowanie

Pamiętaj, aby chronić dane osobowe i poufne użytkowników, które mogą znajdować się w Referer.

Jeśli używasz tylko źródła, sprawdź, czy możesz zamiast tego użyć nagłówka Origin. Może to ułatwić uzyskanie informacji potrzebnych do debugowania bez konieczności analizowania strony odsyłającej.

Płatności

Dostawcy usług płatniczych mogą polegać na nagłówku Referer przychodzących żądań w celu przeprowadzania kontroli bezpieczeństwa.

Na przykład:

  • Użytkownik klika przycisk Kup na stronie online-shop.example/cart/checkout.
  • online-shop.example przekierowuje do payment-provider.example, aby zarządzać transakcją.
  • payment-provider.example sprawdza Referer tego żądania pod kątem listy dozwolonych wartości Referer skonfigurowanych przez sprzedawców. Jeśli nie pasuje do żadnego wpisu na liście, payment-provider.example odrzuca żądanie. Jeśli tak, użytkownik może przejść do transakcji.

Sprawdzone metody dotyczące kontroli bezpieczeństwa procesu płatności

Jako dostawca usług płatniczych możesz używać Referer jako podstawowego zabezpieczenia przed niektórymi atakami. Jednak sam nagłówek Referer nie jest wiarygodną podstawą do sprawdzenia. Witryna wysyłająca żądanie, niezależnie od tego, czy jest to legalny sprzedawca, może ustawić zasadę no-referrer, która sprawi, że informacje Referer będą niedostępne dla dostawcy usług płatniczych.

Sprawdzenie Referer może pomóc dostawcom usług płatniczych wykryć niedoświadczonych hakerów, którzy nie ustawili zasady no-referrer. Jeśli używasz Referer jako pierwszej metody weryfikacji:

  • Nie oczekuj, że parametr Referer będzie zawsze obecny. Jeśli jest obecny, sprawdź go pod kątem minimalnych danych, które może zawierać, czyli źródła.
    • Podczas ustawiania listy dozwolonych wartości Referer upewnij się, że uwzględniasz tylko źródło, a nie ścieżkę.
    • Na przykład dozwolone wartości Referer dla online-shop.example powinny być online-shop.example, a nie online-shop.example/cart/checkout. Jeśli nie oczekujesz żadnej wartości Referer lub oczekujesz wartości Referer, która jest tylko źródłem witryny wysyłającej żądanie, unikniesz błędów, które mogą wynikać z założeń dotyczących Referrer-Policy sprzedawcy.
  • Jeśli nie ma Referer lub jeśli jest, a podstawowe sprawdzenie źródła Referer zakończyło się powodzeniem, możesz przejść do innej, bardziej niezawodnej metody weryfikacji.

Aby bardziej niezawodnie weryfikować płatności, pozwól osobie wysyłającej żądanie haszować parametry żądania wraz z unikalnym kluczem. Dostawcy usług płatniczych mogą następnie obliczyć ten sam skrót po swojej stronie i zaakceptować żądanie tylko wtedy, gdy jest ono zgodne z ich obliczeniami.

Co się dzieje z nagłówkiem Referer, gdy witryna sprzedawcy korzystająca z protokołu HTTP i nieposiadająca zasad dotyczących strony odsyłającej przekierowuje do dostawcy usług płatniczych korzystającego z protokołu HTTPS?

W żądaniu do dostawcy usług płatniczych HTTPS nie jest widoczny żaden Referer, ponieważ większość przeglądarek domyślnie używa strict-origin-when-cross-origin lub no-referrer-when-downgrade, gdy witryna nie ma ustawionej zasady. Zmiana domyślnych zasad w Chrome nie wpłynie na to zachowanie.

Podsumowanie

Zasady dotyczące odsyłaczy chroniące prywatność to świetny sposób na zapewnienie użytkownikom większej prywatności.

Aby dowiedzieć się więcej o różnych technikach ochrony użytkowników, zapoznaj się z naszą kolekcją Bezpieczeństwo i ochrona.

Zasoby

Dziękujemy wszystkim recenzentom za ich wkład i opinie, a w szczególności Kaustubha Govind, Davidowi Van Cleve, Mike'owi Westowi, Samowi Duttonowi, Rowanowi Merewoodowi, Jxckowi i Kayce Basques.