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 zasad odsyłających używając strony odsyłającej w żądaniach przychodzących.

Podsumowanie

• Nieoczekiwany wyciek informacji z innych domen szkodzi użytkownikom internetu prywatności. O zabezpieczeń dotyczących stron odsyłających.
• Rozważ ustawienie zasady dotyczącej stron odsyłających na strict-origin-when-cross-origin. it zachowuje większość użyteczności strony odsyłającej, minimalizując jednocześnie ryzyko wycieku danych między domenami.
• Nie używaj stron odsyłających do ochrony przed fałszowaniem żądań w różnych witrynach (CSRF). Używaj Tokeny CSRF a inne nagłówki jako dodatkowe zabezpieczenie.

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 stronie site-one, z której przesłano żądanie.

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

• żądania nawigacji, gdy użytkownik kliknie link.
• żądań zasobów podrzędnych, gdy przeglądarka wysyła żądania obrazów, elementów iframe, skryptów i inne zasoby, których potrzebuje strona.

W przypadku elementów nawigacyjnych i elementów iframe możesz też uzyskać dostęp do tych danych za pomocą JavaScriptu, wykorzystując kod document.referrer

Z wartości Referer możesz się wiele dowiedzieć. Może to być na przykład usługa analityczna, mogą ich użyć do określenia, że 50% użytkowników witryny site-two.example odwiedziło od social-network.example. Jeśli jednak pełny adres URL, w tym ścieżka i ciągu zapytania, jest wysyłany w Referer w różnych źródłach, może stanowić zagrożenie dla użytkowników prywatności i zagrożenia dla bezpieczeństwa:

Adresy URL 1–5 zawierają informacje prywatne, czasami poufne lub informacje umożliwiające identyfikację. Dyskretne przekazywanie tych danych pomiędzy źródłami może zagrozić użytkowników internetu prywatności.

URL 6 to adres URL funkcji. Jeśli ktoś niż zamierzony użytkownik, haker może przejąć kontrolę konta tego użytkownika.

Aby ograniczyć zakres danych dotyczących stron odsyłających udostępnianych dla żądań z Twojej witryny, możesz określić zasady dotyczące stron odsyłających.

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

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

• Brak danych (brak nagłówka Referer)
• Tylko pochodzenie
• 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: z innej domeny lub z tej samej domeny, niezależnie od tego, czy miejscem docelowym żądania jest bezpieczne jako źródło lub oba te elementy. Pozwala to ograniczyć ilość informacji udostępniane między źródłami lub mniej bezpiecznym źródłom przy zachowaniu bogactwa strony odsyłającej w Twojej witrynie.

W tabeli poniżej pokazujemy, w jaki sposób zasady dotyczące stron odsyłających ograniczają dostępne dane adresów URL w nagłówku strony odsyłającej i document.referrer:

MDN zawiera pełną listę zasad i działań .

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 i HTTP) (strict-origin, no-referrer-when-downgrade i strict-origin-when-cross-origin) traktuje żądania z jednego źródła HTTP do innego źródła HTTP, tak jak w przypadku żądań z jednego punktu początkowego HTTPS do innego. Źródło HTTPS, chociaż protokół HTTP jest mniej bezpieczny. To dlatego, że zasad jest to, czy nastąpi zmiana zabezpieczeń. które czy żądanie może ujawnić dane z zaszyfrowanego źródła w niezaszyfrowanym np. HTTPS → żądania HTTP. Żądanie HTTP → HTTP jest całkowicie niezaszyfrowane, więc nie można przejść na wersję standardową.
• Jeśli żądanie pochodzi z same-origin, oznacza to, że schemat (HTTPS lub HTTP) jest nie zmienia się, więc nie można przejść na niższą wersję zabezpieczeń.

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

Stan na październik 2021 r.

Jeśli nie są ustawione zasady dotyczące stron odsyłających, przeglądarka używa zasad domyślnych.

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

Istnieją różne sposoby ustawiania zasad dotyczących stron odsyłających dla Twojej witryny:

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

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

Nagłówek HTTP i element meta znajdują się na poziomie strony. Kolejność priorytetów dla która określa obowiązującą zasadę elementu:

1. Zasada 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" />

Obraz jest żądane za pomocą zasady no-referrer-when-downgrade, a wszystkie pozostałe żądania zasobów podrzędnych z tej strony są zgodne z strict-origin-when-cross-origin .

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

securityheaders.com pomoże Ci określić, zasady stosowane przez daną witrynę lub stronę.

Możesz też użyć narzędzi dla programistów w przeglądarkach Chrome, Edge lub Firefox, aby wyświetlić zasad dotyczących stron odsyłających wykorzystanych w konkretnym żądaniu. W momencie tego pisania przeglądarka Safari nie pokazuje nagłówka Referrer-Policy, ale pokazuje Referer, który został wysłano.

Jakie zasady należy ustawić w witrynie?

Zdecydowanie zalecamy jednoznaczne ustawienie polityki prywatności, takiej jak: strict-origin-when-cross-origin (lub bardziej rygorystycznie).

Dlaczego „wyraźnie”?

Jeśli nie ustawisz zasad dotyczących stron odsyłających, zostaną zastosowane domyślne zasady przeglądarki – użyć domyślnego ustawienia przeglądarki. Nie jest to jednak idealne rozwiązanie, ponieważ:

• Różne przeglądarki mają różne zasady domyślne, jeśli więc korzystasz z różnych przeglądarek, po ustawieniu wartości domyślnych, witryna nie będzie działać w przewidywalny sposób w różnych przeglądarkach.
• Przeglądarki stosują bardziej rygorystyczne ustawienia domyślne, na przykład strict-origin-when-cross-origin i mechanizmy takie jak przycinanie stron odsyłających dla żądań z innych domen. Wyraźne włączenie zasad zwiększających prywatność. przed zmianą ustawień domyślnych przeglądarki daje Ci kontrolę i ułatwia przeprowadzanie testów które Ci odpowiada.

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

Potrzebujesz bezpiecznych, użytecznych i promujących prywatność zasad. Co jest „przydatne” zależy od tego, czego chcesz od strony odsyłającej:

• Bezpieczeństwo: jeśli witryna używa protokołu HTTPS (jeśli nie, ustaw ją jako ), aby zapobiec wyciekowi adresów URL witryny żądaniami innymi niż HTTPS. Każdy w sieci może to zobaczyć, więc wyciek danych mógłby naraża użytkowników na ataki typu „człowiek pośrodku”. Zasady no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer i strict-origin rozwiązali ten problem.
• Zwiększenie prywatności: w przypadku żądania z innej domeny, no-referrer-when-downgrade udostępnia pełny adres URL, co może spowodować naruszenie prywatności. strict-origin-when-cross-origin i strict-origin mają tylko punkt początkowy, i no-referrer niczego nie udostępnia. Dzięki temu masz strict-origin-when-cross-origin, strict-origin i no-referrer jako zwiększających prywatność.
• Przydatny: no-referrer i strict-origin nigdy nie udostępniają pełnego adresu URL, nawet dla żądań z tej samej domeny. Jeśli potrzebujesz pełnego adresu URL, strict-origin-when-cross-origin to lepsza opcja.

Wszystko to oznacza, że strict-origin-when-cross-origin jest zwykle rozsądnego wyboru.

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 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 rygorystyczny) nie pasuje do wszystkich Twoich przypadków użycia?

W tym przypadku zastosuj stopniowe podejście: ustal zasadę ochronną, taką jak strict-origin-when-cross-origin dla witryny oraz, w razie potrzeby, mniej rygorystycznych zasad w odniesieniu do 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 ograniczyć nagłówek document.referrer lub nagłówek Referer w przypadku żądania z różnych witryn. Zobacz szczegóły.

Przykład: zasada 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 określonych przez Ciebie z zespołem i firmą. Jeśli niektóre adresy URL zawierają dane umożliwiające identyfikację lub dane wrażliwe, określić zasadę ochronną.

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

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

Ochrona użytkowników dane

Pole Referer może zawierać dane prywatne, osobowe lub umożliwiające identyfikację, więc upewnij się, traktujesz to w ten sposób.

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

Korzystanie z strony odsyłającej z przychodzących żądań z innej domeny wiąże się z kilkoma ograniczeniami:

• Jeśli nie masz kontroli nad implementacją nadawcy żądań, nie możesz zastosuj swoje założenia dotyczące nagłówka Referer (i document.referrer), i odbieraj informacje. Nadawca żądań może zdecydować się na przełączenie się na zasadę no-referrer w dowolnym momencie lub bardziej ogólnie na bardziej rygorystyczne zasady przed uruchomieniem. Oznacza to, że odbierasz mniej danych z Referer niż do tej pory.
• Przeglądarki coraz częściej używają zasady odsyłającej strict-origin-when-cross-origin domyślnie. Oznacza to, że możesz teraz otrzymywać tylko informacje o źródle pełny adres URL strony odsyłającej w przychodzących żądaniach z innych domen, jeśli witryna nadawcy nie ma ustawionych zasad.
• Przeglądarki mogą zmienić sposób zarządzania domeną Referer. Na przykład jakaś przeglądarka deweloperzy mogą zdecydować, aby zawsze przycinać strony odsyłające do źródeł w innych domenach. żądania zasobów podrzędnych w celu ochrony prywatności użytkowników.
• Nagłówek Referer (oraz document.referrer) może zawierać więcej danych niż których potrzebujesz. Pełny adres URL może być na przykład pełny, gdy chcesz tylko sprawdzić, czy Żądanie pochodzi z innej domeny.

Alternatywy dla: Referer

Rozważ inne rozwiązania, jeśli:

• Niezbędna funkcja witryny wykorzystuje adres URL strony odsyłającej żądania z innych domen.
• Twoja witryna nie otrzymuje już części adresu URL strony odsyłającej, której potrzebuje w z innej domeny. Dzieje się tak, gdy podmiot wysyłający żądania zmienia swój zasady lub gdy nie są skonfigurowane zasady, a zasady przeglądarki zostały zmienione (jak w Chrome 85).

Aby zdefiniować opcje alternatywne, najpierw przeanalizuj, jakiej części strony odsyłającej używasz.

Jeśli potrzebujesz tylko punktu początkowego

• Jeśli używasz strony odsyłającej w skrypcie z dostępem najwyższego poziomu do strony, window.location.origin to opcja alternatywna.
• Nagłówki takie jak Origin i Sec-Fetch-Site zwraca kod Origin lub opisz, czy żądanie pochodzi z innej domeny, co może okazać się dokładnie tym, czego potrzebujesz.

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

• Parametry żądania mogą dotyczyć Twojego przypadku użycia, dzięki czemu nie musisz poświęcać czasu podczas analizowania strony odsyłającej.
• Jeśli używasz strony odsyłającej w skrypcie z dostępem najwyższego poziomu do strony, Możesz zamiast tego użyć adresu window.location.pathname. Wyodrębnij tylko ścieżkę adresu URL i przekazują go jako argument, dzięki czemu wszelkie potencjalnie poufne informacje określone w parametrach adresu URL nie są przekazywane.

Jeśli nie możesz użyć tych rozwiązań alternatywnych:

• Sprawdź, czy możesz zmienić systemy tak, aby oczekiwać nadawcy żądania (np. site-one.example), aby wyraźnie wskazać informacje, których potrzebujesz. w jakiejś konfiguracji.
  • Za: bardziej wulgarne, lepiej chroniące prywatność użytkowników aplikacji site-one.example, i lepiej przygotować się na przyszłość.
  • Wada: potencjalnie więcej pracy z Twojej strony lub dla użytkowników systemu.
• Sprawdź, czy witryna przesyłająca żądania może zgodzić się na ustawienie dla poszczególnych elementów lub żądań dotyczących stron odsyłających dla wartości no-referrer-when-downgrade.
  • Wada: potencjalnie mniejsza ochrona prywatności w przypadku site-one.example użytkowników. może nie być obsługiwana przez niektóre przeglądarki.

Ochrona przed fałszowaniem żądań w różnych witrynach

Nadawca żądań może zawsze zdecydować, że nie wyśle strony odsyłającej, ustawiając parametr no-referrer, a haker może nawet sfałszować stronę odsyłającą.

Używanie tokenów CSRF jako podstawowe zabezpieczenie. Aby zapewnić sobie dodatkową ochronę, używaj SameSite, zamiast Referer, użyj nagłówków takich jak Origin (dostępne w przypadku żądań POST i CORS) oraz Sec-Fetch-Site jeśli jest dostępna.

Logowanie i debugowanie

Chroń użytkowników danych osobowych lub poufnych, które mogą znajdować się Referer

Jeśli używasz tylko punktu początkowego, sprawdź, czy możesz użyć Origin jako nagłówek i innych rozwiązań. Dzięki temu możesz uzyskać informacje potrzebne do debugowania bez potrzeby analizowania strony odsyłającej.

Płatności

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

Na przykład:

• Użytkownik klika przycisk Kup w usłudze online-shop.example/cart/checkout.
• online-shop.example przekierowuje na adres payment-provider.example, aby zarządzać transakcji.
• payment-provider.example porównuje element Referer tego żądania z listą z dozwolonych wartości Referer skonfigurowanych przez sprzedawców. Jeśli nie, pozycja na liście, payment-provider.example odrzuca prośbę. 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 podstawowej formy weryfikacji pod kątem ataków. Jednak sam nagłówek Referer nie stanowi niezawodnej podstawy sprawdzić. Niezależnie od tego, czy jest to oficjalny sprzedawca, witryna wysyłająca żądanie może ustawić zasada no-referrer, która sprawia, że informacje z tabeli Referer są niedostępne dla dostawcy usług płatniczych.

Referer może pomóc dostawcom usług płatniczych wychwytywać naiwnych ataków, nie ustawiono zasady no-referrer. Jeśli używasz Referer do pierwszego sprawdzenia:

• Nie oczekuj, że pole Referer będzie zawsze obecne. Sprawdź, jeśli znajduje się na liście. jedynie z minimalną ilością danych, które mogą zawierać dane, czyli ich źródłem.
  • Podczas ustawiania listy dozwolonych wartości Referer należy uwzględnić tylko od źródła bez ścieżki.
  • Na przykład dozwolone wartości Referer w polu online-shop.example powinny być online-shop.example, a nie online-shop.example/cart/checkout. Oczekując w ogóle nie ma wartości Referer lub wartość Referer jest tylko żądaniem , zapobiegasz błędom, które mogą wynikać z przyjmowania założeń o Referrer-Policy sprzedawcy.
• Jeśli brakuje parametru Referer lub jeśli występuje, a także Twoje podstawowe źródło Referer będzie można przejść do innej, bardziej niezawodnej weryfikacji .

Aby dokładniej zweryfikować płatności, zezwó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 zaakceptuj je tylko wtedy, gdy będą zgodne z Twoimi obliczeniami.

Co się dzieje z adresem Referer, gdy witryna sprzedawcy HTTP bez strony odsyłającej przekierowuje użytkownika do dostawcy usług płatniczych HTTPS?

W żądaniu wysyłanym do dostawcy usług płatniczych HTTPS nie jest widoczny żaden element Referer, ponieważ większość przeglądarek używa strict-origin-when-cross-origin lub Domyślnie no-referrer-when-downgrade, jeśli witryna nie ma ustawionych zasad. Zmiana zasad Chrome na nową zasadę domyślną nie zmieni tego zachowania.

Podsumowanie

Ochronne zasady dotyczące stron odsyłających to doskonały 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 Bezpieczne zbieranie danych

Zasoby

• Co to jest „ta sama witryna” i „same-origin”
• Nowy nagłówek zabezpieczeń: zasada odsyłająca (2017 r.)
• Zasady dotyczące stron odsyłających MDN
• Nagłówek strony odsyłającej: kwestie prywatności i bezpieczeństwa włączone MDN
• Zmiana w Chrome: intencja mrugnięcia zaimplementuj
• Zmiana w Chrome: intencja mrugnięcia statek
• Zmiana w Chrome: wpis stanu
• Zmiana w Chrome: wersja beta 85 blogpost
• Strona odsyłająca przycina wątek z GitHub: jakie przeglądarki tak
• Specyfikacja zasad dotyczących stron odsyłających

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