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

Maud Nalpas

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

Podsumowanie

• Nieoczekiwane wycieki informacji między domenami naruszają prywatność użytkowników. Mogą w tym pomóc chroniczne zasady dotyczące stron odsyłających.
• Rozważ ustawienie zasad dotyczących stron odsyłających na wartość strict-origin-when-cross-origin. Zachowuje przydatność odesłania, jednocześnie ograniczając ryzyko wycieku danych między domenami.
• Nie używaj odesłań do ochrony przed fałszowaniem żądań między witrynami (CSRF). Zamiast tego użyj tokenów CSRF i innych nagłówków jako dodatkowej warstwy zabezpieczeń.

Podstawy zasad dotyczących stron odsyłających

Żą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 tym przykładzie nagłówek Referer zawiera pełny adres URL strony site-one, z której wysłano żądanie.

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

• żądania nawigacyjne, gdy użytkownik klika link;
• żądania zasobów podrzędnych, gdy przeglądarka wysyła żądanie obrazów, ramek 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ą JavaScriptu za pomocą funkcji document.referrer.

Z wartości Referer możesz się wiele dowiedzieć. Na przykład usługa analityczna może użyć tych danych, aby ustalić, że 50% użytkowników witryny site-two.example pochodziło z witryny social-network.example. Jednak gdy pełny adres URL, w tym ścieżka i ciąg znaków zapytania, jest wysyłany w Referer między różnymi źródłami, może to zagrozić prywatności użytkowników i stworzyć zagrożenia bezpieczeństwa:

Adresy URL 1–5 zawierają informacje prywatne, a czasami informacje poufne lub umożliwiające identyfikację. Ich wyciek do różnych źródeł może naruszyć prywatność użytkowników.

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

Aby ograniczyć dane o stronie odsyłającej udostępniane w przypadku żądań z Twojej witryny, możesz ustawić zasadę dotyczącą 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 zasady dane dostępne z nagłówka Referer (i elementu document.referrer) mogą być:

• Brak danych (brak nagłówka Referer)
• Tylko punkt początkowy
• Pełny adres URL: pochodzenie, ścieżka i ciąg zapytania

Niektóre zasady działają różnie w zależności od kontekstu: żądania z innej domeny lub tej samej domeny, od tego, czy miejsce docelowe żądania jest tak bezpieczne jak źródło, czy z obu tych źródeł. Pozwala to ograniczyć ilość informacji udostępnianych między źródłami lub mniej bezpiecznymi źródłami, zachowując jednocześnie bogactwo informacji o stronie odsyłającej w Twojej witrynie.

Poniższa tabela pokazuje, jak zasady dotyczące strony odsyłającej ograniczają dane adresu URL dostępne w nagłówku Referer i w pliku document.referrer:

MDN zawiera pełną listę zasad i przykładów działania.

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

• 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, mimo że protokół HTTP jest mniej bezpieczny. Wynika to z tego, że w przypadku tych zasad ważne jest, czy dochodzi do obniżenia poziomu zabezpieczeń, czyli czy żądanie może ujawnić dane z zaszyfrowanego źródła do niezaszyfrowanego, jak w przypadku żądań HTTPS → HTTP. Żądanie HTTP → HTTP jest całkowicie niezaszyfrowane, więc nie ma możliwości obniżenia poziomu zabezpieczeń.
• Jeśli żądanie pochodzi z same-origin, oznacza to, że schemat (HTTPS lub HTTP) jest taki sam, więc nie ma przejścia na niższą wersję zabezpieczeń.

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

Październik 2021 r.

Jeśli nie skonfigurujesz zasad dotyczących strony odsyłającej, przeglądarka zastosuje swoje domyślne zasady.

Sprawdzone metody konfigurowania zasad dotyczących odesłania

Możesz ustawić zasady dotyczące witryn odsyłających na różne sposoby:

• Jako nagłówek HTTP
• W pliku HTML
• Z JavaScriptu dla poszczególnych żądań

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

Zarówno nagłówek HTTP, jak i element meta znajdują się na poziomie strony. Priorytet wyznaczania skutecznej zasady elementu wygląda tak:

1. Zasady na poziomie elementu
2. Zasady na poziomie strony
3. Domyślne ustawienie przeglądarki

Przykład:

index.html:

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

Prośba o obraz jest zgodna z zasadami no-referrer-when-downgrade, a wszystkie inne prośby o subresursy na tej stronie są zgodne z zasadami strict-origin-when-cross-origin.

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

securityheaders.com pozwala ustalić, jakich zasad używa dana witryna lub strona.

Aby sprawdzić zasady dotyczące odesłań używane w przypadku konkretnego żądania, możesz też użyć narzędzi dla programistów w Chrome, Edge lub Firefox. W momencie pisania tego tekstu Safari nie wyświetla nagłówka Referrer-Policy, ale pokazuje wysłany nagłówek Referer.

Jakie zasady należy ustawić w przypadku witryny?

Zdecydowanie zalecamy wyraźne skonfigurowanie polityki zwiększającej prywatność, takiej jak strict-origin-when-cross-origin (lub bardziej restrykcyjnej).

Dlaczego „wyraźnie”?

Jeśli nie ustawisz zasad dotyczących stron odsyłających, zostaną użyte domyślne zasady przeglądarki – w rzeczywistości witryny często w ogóle będą ją zmieniać. Nie jest to jednak idealne rozwiązanie, ponieważ:

• Różne przeglądarki mają różne domyślne zasady, więc jeśli korzystasz z domyślnych ustawień przeglądarki, Twoja witryna może zachowywać się w różny sposób w różnych przeglądarkach.
• Przeglądarki stosują 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 zaakceptowanie zasad zwiększających prywatność przed zmianą domyślnych ustawień przeglądarki daje Ci kontrolę i ułatwia przeprowadzanie testów wedle uznania.

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

Potrzebujesz bezpiecznych, użytecznych i promujących prywatność zasad. Co oznacza „przydatne”? To zależy od tego, czego oczekujesz od witryn odsyłających:

• Bezpieczeństwo: jeśli Twoja witryna korzysta z protokołu HTTPS (jeśli nie, nadaj mu priorytet), nie chcesz, aby adresy URL Twojej witryny były widoczne w żądaniach bez protokołu HTTPS. Ponieważ każdy w sieci może je zobaczyć, wycieki mogą narazić użytkowników na ataki typu „człowiek w środku”. Ten problem rozwiązują zasady no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer i strict-origin.
• Zwiększenie prywatności: w przypadku żądania między domenami 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 mają tylko wspólne pochodzenie, a no-referrer nie ma nic wspólnego z innymi. Pozostają więc opcje strict-origin-when-cross-origin, strict-origin i no-referrer, które zwiększają prywatność.
• Użyteczne: 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.

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

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

index.html:

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

Lub po stronie serwera, na przykład w usłudze 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 restrykcyjne) nie wystarcza do wszystkich przypadków użycia?

W takim przypadku zastosuj stopniowe podejście: ustaw w swojej witrynie zasady ochrony takie jak strict-origin-when-cross-origin, a w razie potrzeby bardziej liberalne zasady dotyczące określonych żą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ń międzywitrynowych. Zobacz szczegóły

Przykład: zasady na poziomie żądania

script.js:

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

Co jeszcze warto wziąć pod uwagę?

Twoje zasady powinny zależeć od Twojej witryny i przypadków użycia, które zostały określone przez Ciebie, Twój zespół i Twoją firmę. Jeśli niektóre adresy URL zawierają dane identyfikacyjne lub 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 witryny odsyłającej w przypadku żądań przychodzących.

Ochrona danych użytkowników

Plik Referer może zawierać dane prywatne, osobiste lub umożliwiające identyfikację, dlatego należy traktować go jako taki.

Odsyłający może się zmienić {referer-can-change}

Korzystanie z odwołania w przypadku przychodzących żądań między domenami ma kilka ograniczeń:

• Jeśli nie masz kontroli nad implementacją emitenta żądania, nie możesz zakładać niczego na temat nagłówka Referer (ani document.referrer), który otrzymujesz. Emitent żądania może w dowolnym momencie zdecydować się na zastosowanie zasad no-referrer lub ogólnie bardziej rygorystycznych zasad niż te, których 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 przypadku przychodzących żądań z innych domen możesz otrzymać tylko źródło, a nie pełny adres URL strony odsyłającej, jeśli strona nadawcza nie ma ustawionych 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ć referrery w żądaniach zasobów podrzędnych z innych źródeł.
• Nagłówek Referer (i document.referrer) może zawierać więcej danych, niż potrzebujesz. Może to być np. pełny adres URL, gdy chcesz tylko wiedzieć, czy żądanie pochodzi z innego źródła.

Alternatywy dla Referer

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

• Podstawowa funkcja witryny korzysta z adresu URL witryny odsyłającej w przypadku przychodzących żądań między domenami.
• Twoja witryna nie otrzymuje już części adresu URL strony odsyłającej, której potrzebuje w żądaniu z innej domeny. Dzieje się tak, gdy nadawca żądania zmienił zasady lub gdy nie ma skonfigurowanych zasad, a zmieniły się domyślne zasady przeglądarki (np. w Chrome 85).

Aby określić alternatywne wartości, najpierw przeanalizuj, której części odwołania 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 najwyższego poziomu, możesz użyć opcji window.location.origin.
• Jeśli są dostępne, nagłówki takie jak Origin i Sec-Fetch-Site podają Origin lub opisują, czy żądanie jest między domenami, 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ć odpowiednie do Twojego przypadku użycia, co pozwoli Ci zaoszczędzić czas na analizowaniu odesłań.
• Jeśli używasz strony odsyłającej w skrypcie, który ma dostęp do strony najwyższego poziomu, jako alternatywę możesz użyć parametru window.location.pathname. Wyodrębnij tylko część ścieżki adresu URL i przekaż ją jako argument, aby nie przekazywać potencjalnie poufnych informacji zawartych w parametrach adresu URL.

Jeśli nie możesz skorzystać z tych alternatyw:

• Sprawdź, czy możesz zmienić swoje systemy, aby oczekiwać, że nadawca żądania (na przykład site-one.example) będzie wyraźnie ustawiać potrzebne informacje w jakimś rodzaju konfiguracji.
  • Za: bardziej dosłowne, lepiej chroniące prywatność użytkowników site-one.example i bardziej przyszłościowe.
  • Minus: 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 wartości no-referrer-when-downgrade w zasadach odnośnie odesłania dla poszczególnych elementów lub żądań.
  • Wada: potencjalnie gorsza ochrona prywatności w przypadku użytkowników korzystających z usługi site-one.example; potencjalnie nieobsługiwana w niektórych przeglądarkach.

Ochrona przed atakami CSRF (Cross-Site Request Forgery)

Nadawca żądań może zawsze zdecydować, że nie wyśle strony odsyłającej, ustawiając zasadę no-referrer. Złośliwy podmiot może nawet podszywać się pod stronę odsyłającą.

Użyj tokenów CSRF jako głównej ochrony. Aby zapewnić dodatkową ochronę, użyj ustawienia SameSite, a zamiast nagłówka Referer użyj nagłówków takich jak Origin (dostępnych w przypadku żądań POST i CORS) oraz Sec-Fetch-Site (jeśli jest dostępny).

Rejestrowanie i debugowanie

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

Jeśli używasz tylko pochodzenia, sprawdź, czy możesz użyć nagłówka Origin jako alternatywy. Dzięki temu możesz uzyskać informacje potrzebne do debugowania w prostszy sposób i bez konieczności analizowania wartości referrera.

Płatności

Dostawcy płatności mogą używać nagłówka Referer przychodzących żądań do przeprowadzania kontroli bezpieczeństwa.

Na przykład:

• Użytkownik klika przycisk Kup na stronie online-shop.example/cart/checkout.
• Domena online-shop.example przekierowuje do domeny payment-provider.example, aby umożliwić zarządzanie transakcją.
• payment-provider.example sprawdza Referer tej prośby na liście dozwolonych wartości Referer skonfigurowanych przez sprzedawców. Jeśli nie pasuje do żadnego elementu na liście, payment-provider.example odrzuca prośbę. Jeśli się zgadza, użytkownik może dokonać transakcji.

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

Jako dostawca płatności możesz używać Referer jako podstawowej kontroli w celu ochrony przed niektórymi atakami. Jednak sam nagłówek Referer nie stanowi wiarygodnej podstawy weryfikacji. Witryna, która wysłała żądanie, niezależnie od tego, czy jest to wiarygodny sprzedawca, czy nie, może ustawić zasady no-referrer, które uniemożliwiają dostawcy płatności dostęp do informacji Referer.

Sprawdzanie Referer może pomóc dostawcom usług płatniczych w łapaniu naiwnych hakerów, którzy nie skonfigurowali zasad no-referrer. Jeśli używasz Referer do pierwszego sprawdzenia:

• Nie oczekuj, że Referer będzie zawsze obecne. Jeśli jest obecny, sprawdź go, porównując z minimalnymi danymi, które może zawierać, czyli z pochodzeniem.
  • Podczas ustawiania listy dozwolonych wartości Referer uwzględnij tylko źródło, a nie ścieżkę.
  • Na przykład dozwolone wartości atrybutu Referer dla atrybutu online-shop.example to online-shop.example, a nie online-shop.example/cart/checkout. Oczekiwanie braku wartości Referer lub wartości Referer, która jest tylko źródłem witryny przesyłającej żądanie, zapobiega błędom, które mogą wystąpić w przypadku tworzenia założeń dotyczących Referrer-Policy sprzedawcy.
• Jeśli Referer nie ma lub jeśli jest obecny, a podstawowe sprawdzenie źródła Referer się powiedzie, możesz przejść do innej, bardziej niezawodnej metody weryfikacji.

Aby weryfikacja płatności była bardziej niezawodna, pozwól osobie zgłaszającej prośbę zaszyfrować parametry żądania razem z unikalnym kluczem. Dostawcy usług płatniczych mogą wtedy obliczyć ten sam hasz po Twojej stronie i zaakceptować żądanie tylko wtedy, gdy odpowiada ono Twoim obliczeniom.

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

W żądaniu wysłanym do dostawcy płatności HTTPS nie ma widocznego parametru Referer, ponieważ większość przeglądarek domyślnie używa parametru strict-origin-when-cross-origin lub no-referrer-when-downgrade, gdy witryna nie ma ustawionych zasad. Zmiana domyślnych zasad Chrome nie zmieni tego zachowania.

Podsumowanie

Zasady dotyczące chronionego odesłania 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 kolecji Bezpieczeństwo i bezpieczeństwo.

Zasoby

• Znaczenie terminów „ten sam zasób” i „ten sam element”
• Nowy nagłówek zabezpieczeń: polityka dotycząca odnośnika (2017 r.)
• Referrer-Policy w MDN
• Nagłówek referrera: kwestie prywatności i bezpieczeństwa w MDN
• Zmiana w Chrome: wdrożenie intencji Blink
• Zmiany w Chrome: zamiar wdrożenia Blink
• Zmiana w Chrome: wpis stanu
• Zmiany w Chrome: wersja beta 85
• Wycięcie odnośnika w wątku na GitHubie: co robią różne przeglądarki?
• Specyfikacja zasady dotyczącej strony odsyłającej

Dziękujemy wszystkim recenzentom za ich wkład i opinie, zwłaszcza Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck i Kayce Basques.