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 odsyłającego w przychodzących żądaniach.

Podsumowanie

• Nieoczekiwany wyciek informacji z różnych źródeł narusza prywatność użytkowników internetu. Pomocne mogą być ochronne zasady dotyczące stron odsyłających.
• Rozważ ustawienie zasady dotyczącej stron odsyłających na strict-origin-when-cross-origin. Zachowuje większość przydatnych informacji o witrynie odsyłającej, jednocześnie zmniejszając ryzyko wycieku danych między domenami.
• Nie używaj odsyłaczy do ochrony przed atakami typu CSRF (Cross-Site Request Forgery). 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.

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 dotyczące obrazów, elementów iframe, skryptów i innych zasobów potrzebnych stronie.

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.

Wiele można się nauczyć z wartości Referer. Na przykład usługa analityczna może ich używać do określania, że 50% osób odwiedzających witrynę site-two.example pochodzi z social-network.example. Gdy jednak pełny adres URL, w tym ścieżka i ciąg zapytania, jest wysyłany w ramach Referer żądania dotyczącego różnych domen, może to zagrażać prywatności użytkownika i stwarzać zagrożenia dla bezpieczeństwa:

Adresy URL od 1 do 5 zawierają informacje prywatne, a czasami informacje poufne lub umożliwiające identyfikację. Ciche wycieki tych informacji między różnymi źródłami mogą naruszać prywatność użytkowników internetu.

Adres URL 6 to adres URL funkcji. Jeśli otrzyma ją ktoś inny niż docelowy użytkownik, nieuczciwy podmiot może przejąć kontrolę nad jego kontem.

Aby ograniczyć dane o stronie odsyłającej 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

Niektóre zasady są zaprojektowane tak, aby zachowywać się inaczej w zależności od kontekstu: żądania pochodzącego z innego źródła lub z tego samego źródła, tego, czy miejsce docelowe żądania jest tak samo bezpieczne jak źródło, lub obu tych czynników. Jest to przydatne, aby ograniczyć ilość informacji udostępnianych w różnych domenach lub w mniej bezpiecznych domenach, przy jednoczesnym zachowaniu szczegółowości informacji o odesłaniu w obrębie własnej witryny.

W tabeli poniżej znajdziesz informacje o tym, jak zasady dotyczące odsyłającego ograniczają dane URL dostępne w nagłówku Referer i document.referrer:

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

Podczas ustawiania zasady dotyczącej odsyłającego pamiętaj o tych kwestiach:

• 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 ze źródła HTTPS do innego źródła HTTPS, mimo że HTTP jest mniej bezpieczny. Dzieje się tak, ponieważ w przypadku tych zasad istotne jest, czy następuje obniżenie poziomu zabezpieczeń, czyli czy żądanie może ujawnić dane z zaszyfrowanego źródła w niezaszyfrowanym, jak w przypadku żądań HTTPS → HTTP. Żądanie HTTP → HTTP jest w całości niezaszyfrowane, więc nie ma tu 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 ma obniżenia poziomu bezpieczeństwa.

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

Od października 2021 r.

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

Sprawdzone metody ustawiania zasady dotyczącej adresu odsyłającego

Zasady dotyczące odsyłającego możesz ustawić w witrynie na kilka sposobów:

• Jako nagłówek HTTP
• W HTML
• z JavaScriptu w przypadku każdego żądania,

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

Zarówno nagłówek HTTP, jak i element meta są na poziomie strony. Kolejność priorytetów przy określaniu obowiązujących zasad dotyczących elementu jest następująca:

1. Zasady na poziomie elementu
2. Zasady na poziomie strony
3. Domyślna przeglądarka

Przykład:

index.html:

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

Obraz jest żądany z zasadą 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 sprawdzić zasady dotyczące odsyłającego?

securityheaders.com to przydatne narzędzie 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 Firefox, aby sprawdzić zasady dotyczące odsyłania używane w przypadku konkretnego żądania. W momencie pisania tego artykułu Safari nie wyświetla nagłówka Referrer-Policy, ale wyświetla wysłany nagłówek Referer.

Jakie zasady należy ustawić w przypadku witryny?

Zdecydowanie zalecamy wyraźne ustawienie zasady zwiększającej ochronę prywatności, np. 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. W rzeczywistości witryny często odwołują się do domyślnej zasady 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 domyślnych ustawieniach przeglądarki, Twoja witryna nie będzie działać w przewidywalny sposób w różnych przeglądarkach.
• Przeglądarki przyjmują bardziej rygorystyczne ustawienia domyślne, takie jak strict-origin-when-cross-origin, oraz mechanizmy, takie jak przycinanie strony odsyłającej w przypadku żądań z innych domen. Wyrażenie zgody na zasady zwiększające ochronę prywatności przed zmianą ustawień domyślnych przeglądarki daje Ci kontrolę i umożliwia przeprowadzanie testów w odpowiedni dla Ciebie sposób.

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

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

• Zabezpieczona: jeśli Twoja witryna używa protokołu HTTPS (jeśli nie, potraktuj to jako priorytet), nie chcesz, aby adresy URL witryny wyciekały w żądaniach innych niż HTTPS. Ponieważ każdy w sieci może je zobaczyć, wycieki mogą narazić użytkowników na ataki typu „man-in-the-middle”. Rozwiązaniem tego problemu są zasady no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer i strict-origin.
• Zwiększające prywatność: w przypadku żądania z innej domeny no-referrer-when-downgradeudostępnia pełny adres URL, co może powodować problemy z prywatnością. strict-origin-when-cross-origin i strict-origin udostępniają tylko pochodzenie, a no-referrer nie udostępnia niczego. W takiej sytuacji opcje zwiększające prywatność to 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ń pochodzących z tej samej domeny. Jeśli potrzebujesz pełnego adresu URL, lepszym rozwiązaniem jest strict-origin-when-cross-origin.

Oznacza to, że strict-origin-when-cross-origin jest zwykle rozsądnym wyborem.

Przykład: ustawianie strict-origin-when-cross-origin zasad

index.html:

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

lub po stronie serwera, np. w Express:

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

Co zrobić, jeśli poziom strict-origin-when-cross-origin (lub wyższy) nie obejmuje wszystkich przypadków użycia?

W takim przypadku zastosuj podejście progresywne: ustaw w witrynie zasady ochrony, np.strict-origin-when-cross-origin, a w razie potrzeby bardziej liberalne zasady w przypadku konkretnych żą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ń w witrynach. Zobacz szczegóły

Przykład: zasady 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, 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 politykę ochrony.

Sprawdzone metody dotyczące przychodzących próśb

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

Ochrona danych użytkowników

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

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

Korzystanie z informacji o stronie odsyłającej w przypadku przychodzących żądań z innych domen ma pewne ograniczenia:

• Jeśli nie masz kontroli nad implementacją podmiotu wysyłającego żądanie, nie możesz zakładać, że otrzymasz nagłówek Referer (i document.referrer). Nadawca żądania może w dowolnym momencie przejść na zasady no-referrer lub ogólnie na bardziej rygorystyczne zasady niż te , których używał wcześniej. Oznacza to, że otrzymujesz z Referer mniej danych niż wcześniej.
• Przeglądarki coraz częściej domyślnie używają zasady Referrer-Policy.strict-origin-when-cross-origin Oznacza to, że w przypadku przychodzących żądań z innych domen możesz teraz otrzymywać tylko źródło, a nie pełny adres URL strony odsyłającej, jeśli witryna wysyłająca nie ma ustawionych zasad.
• Przeglądarki mogą zmienić sposób zarządzania Referer. Na przykład niektórzy deweloperzy przeglądarek mogą zdecydować się na zawsze przycinać adresy URL odsyłające do źródeł w przypadku żądań 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. Na przykład może zawierać pełny adres URL, gdy chcesz tylko sprawdzić, czy żądanie pochodzi z innej domeny.

Alternatywy dla Referer

Alternatywne rozwiązania mogą być potrzebne, jeśli:

• Podstawowa funkcja witryny korzysta z adresu URL odsyłającego przychodzących żądań z innych domen.
• Twoja witryna nie otrzymuje już części adresu URL strony odsyłającej, która jest potrzebna w przypadku żądania z innej domeny. Dzieje się tak, gdy podmiot wysyłający żądanie zmieni swoją zasadę lub gdy nie ma ustawionej zasady, a zmieni się domyślna zasada przeglądarki (np. w Chrome 85).

Aby zdefiniować alternatywy, najpierw przeanalizuj, której części adresu odsyłającego używasz.

Jeśli potrzebujesz tylko pochodzenia

• Jeśli używasz strony odsyłającej w skrypcie, który ma dostęp najwyższego poziomu do strony, 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 pochodzenia mieszanego, 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ą być odpowiednie w Twoim przypadku użycia, co pozwoli Ci uniknąć analizowania adresu URL strony 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ębnij tylko ścieżkę 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 opcji:

• Sprawdź, czy możesz zmienić systemy, aby oczekiwać, że podmiot wysyłający żądanie (np. site-one.example) będzie w ramach konfiguracji wyraźnie ustawiać potrzebne informacje.
  • Zalety: bardziej jednoznaczne, lepiej chroniące prywatność użytkowników site-one.example, bardziej przyszłościowe.
  • Wada: potencjalnie więcej pracy po Twojej stronie lub po stronie użytkowników systemu.
• Sprawdź, czy witryna, która wysyła żądania, może zgodzić się na ustawienie zasady Referrer-Policy na poziomie elementu lub żądania na wartość no-referrer-when-downgrade.
  • Wada: potencjalnie mniejsza ochrona prywatności użytkowników site-one.example, potencjalnie nieobsługiwana we wszystkich przeglądarkach.

Ochrona przed atakami typu CSRF (Cross-Site Request Forgery)

Nadawca żądania może zawsze zadecydować, że nie wyśle adresu URL strony odsyłającej, ustawiając odpowiednie no-referrerzasady. Nieuczciwy podmiot może nawet sfałszować adres URL strony odsyłającej.

Używaj tokenów CSRF jako głównego zabezpieczenia. Aby zwiększyć ochronę, używaj ustawienia SameSite, a zamiast Referer używaj nagłówków takich jak Origin (dostępny w przypadku żądań POST i CORS) oraz Sec-Fetch-Site, jeśli jest dostępny.

Logowanie i debugowanie

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

Jeśli używasz tylko pochodzenia, sprawdź, czy możesz użyć nagłówka Origin jako alternatywy. Może to ułatwić uzyskanie informacji potrzebnych do debugowania bez konieczności analizowania adresu URL strony odsyłającej.

Płatności

Dostawcy usług płatniczych mogą polegać na nagłówku Referer w przypadku przychodzących żądań, aby przeprowadzać kontrole bezpieczeństwa.

Na przykład:

• Użytkownik klika przycisk Kup na stronie online-shop.example/cart/checkout.
• Domena online-shop.example przekierowuje do payment-provider.example, aby zarządzać transakcją.
• payment-provider.example sprawdza Referer tego żądania z listą dozwolonych wartości Referer skonfigurowaną przez sprzedawców. Jeśli nie pasuje do żadnego wpisu na liście, payment-provider.example odrzuca żądanie. Jeśli się zgadza, 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. Sam nagłówek Referer nie jest jednak wiarygodną podstawą do sprawdzenia. Witryna, która wysłała żądanie, niezależnie od tego, czy jest legalnym sprzedawcą, może ustawić no-referrerzasady, które uniemożliwiają dostawcy usług płatniczych uzyskanie informacji Referer.

Sprawdzanie Referer może pomóc dostawcom usług płatniczych w wykrywaniu niedoświadczonych hakerów, którzy nie skonfigurowali zasady no-referrer. Jeśli używasz metody Referer jako pierwszego sprawdzenia:

• Nie zakładaj, że Referer zawsze będzie obecny. Jeśli jest obecny, sprawdź go tylko pod kątem minimalnych danych, które może zawierać, czyli pochodzenia.
  • 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 dla online-shop.example powinny być online-shop.example, a nie online-shop.example/cart/checkout. Oczekując braku parametru Referer lub wartości Referer, która jest tylko pochodzeniem witryny wysyłającej żądanie, zapobiegasz błędom, które mogą wynikać z założeń dotyczących parametru Referer sprzedawcy.Referrer-Policy
• Jeśli Referer nie występuje lub występuje, a podstawowe sprawdzenie pochodzenia Referer zakończyło się powodzeniem, możesz przejść do innej, bardziej wiarygodnej metody weryfikacji.

Aby bardziej wiarygodnie weryfikować płatności, pozwól osobie wysyłającej żądanie zahaszować parametry żądania wraz z unikalnym kluczem. Dostawcy usług płatniczych mogą wtedy obliczyć ten sam hash po Twojej stronie i zaakceptować prośbę tylko wtedy, gdy będzie on zgodny z Twoimi obliczeniami.

Co się stanie z Referer, gdy witryna sprzedawcy HTTP bez zasad dotyczących odsyłającego przekieruje użytkownika do dostawcy usług płatniczych HTTPS?

W żądaniu wysyłanym do dostawcy usług płatniczych HTTPS nie widać 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 domyślnych zasad Chrome nie wpłynie na to zachowanie.

Podsumowanie

Ochronna polityka odsyłająca to świetny sposób na zapewnienie użytkownikom większej prywatności.

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

Zasoby

• Wyjaśnienie pojęć „ta sama witryna” i „to samo pochodzenie”
• Nowy nagłówek bezpieczeństwa: Referrer Policy (2017)
• Referrer-Policy w MDN
• Nagłówek Referer: kwestie dotyczące prywatności i bezpieczeństwa w MDN
• Zmiana w Chrome: zamiar wdrożenia Blink
• Zmiana w Chrome: zamiar wdrożenia Blink
• Zmiana w Chrome: wpis stanu
• Zmiana w Chrome: wersja beta 85 post na blogu
• Wątek na GitHubie dotyczący przycinania informacji o źródle odesłania: co robią różne przeglądarki
• Specyfikacja zasady dotyczącej strony odsyłającej

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