Best Practices für Verweis-URLs und Referrer-URL-Richtlinien

Maud Nalpas

Auf dieser Seite finden Sie einige Best Practices zum Festlegen der Referrer-URL-Richtlinie und Referrer-URL in eingehenden Anfragen verwenden.

Zusammenfassung

• Unerwartetes ursprungsübergreifendes Informationsleck schädigt Webnutzer Datenschutz. A kann Abhilfe schaffen.
• Legen Sie gegebenenfalls eine Verweisrichtlinie auf strict-origin-when-cross-origin fest. Es bleiben die meiste Nützlichkeit der Verweis-URL erhalten, während gleichzeitig das Risiko ursprungsübergreifenden Datenlecks.
• Verwenden Sie keine Verweis-URLs für den CSRF-Schutz (Cross-Site Request Forgery). Verwenden Sie CSRF-Tokens und andere Header als zusätzliche Sicherheitsebene.

Richtlinie für Referrer-URL und Referrer-URL – Grundlagen

HTTP-Anfragen können einen optionalen Referer-Header enthalten. gibt die URL des Ursprungs oder der Webseite an, über die die Anfrage gestellt wurde. Die Referrer-Policy-Header definiert, welche Daten im Referer-Header zur Verfügung gestellt werden.

Im folgenden Beispiel enthält der Header Referer die vollständige URL des Seite auf site-one, über die der Antrag gestellt wurde.

</ph>

Der Header Referer kann in verschiedenen Arten von Anfragen vorhanden sein:

• Navigationsanfragen, wenn ein Nutzer auf einen Link klickt.
• Anfragen von Unterressourcen, wenn ein Browser Bilder, iFrames, Skripts und andere Ressourcen, die eine Seite benötigt.

Für Navigationen und iFrames können Sie auf diese Daten auch mit JavaScript zugreifen, indem Sie document.referrer

Sie können viel aus Referer-Werten lernen. Beispiel: Ein Analysedienst Sie können damit feststellen, dass 50% der Besucher auf site-two.example von social-network.example. Wenn jedoch die vollständige URL, einschließlich Pfad und in der Referer über mehrere Ursprünge gesendet wird, kann dies Nutzer gefährden. und Sicherheitsrisiken verursachen:

</ph>

Die URLs 1 bis 5 enthalten private Informationen, manchmal aber auch sensible oder identifizierende Informationen. Werden diese unwissentlich über mehrere Ursprünge übertragen, kann das Webnutzer Datenschutz.

URL 6 ist eine Funktions-URL. Falls jemand die nicht der beabsichtigte Nutzer erhält, kann ein böswilliger Akteur die Kontrolle übernehmen. des Kontos dieses Nutzers.

Um einzuschränken, welche Verweisdaten für Anfragen von Ihrer Website zur Verfügung gestellt werden, können Sie eine Verweisrichtlinie festlegen.

Welche Richtlinien sind verfügbar und wie unterscheiden sich diese?

Sie können eine von acht Richtlinien auswählen. Je nach Richtlinie werden die Daten im Referer-Header (und document.referrer) verfügbar sind:

• Keine Daten (kein Referer-Header vorhanden)
• Nur das Feld origin
• Die vollständige URL: Ursprung, Pfad und Abfragestring

</ph>

Einige Richtlinien sind so konzipiert, dass sie sich je nach Kontext unterschiedlich verhalten: ursprungsübergreifende oder Same-Origin-Anfrage, ob das Anfrageziel Secure als Ursprung oder beides. Dies ist nützlich, um die Informationsmenge zwischen Ursprüngen oder weniger sicheren Ursprüngen weitergegeben werden, während die Vielfalt der Referrer-URL auf Ihrer eigenen Website.

Die folgende Tabelle zeigt, wie Verweisrichtlinien die verfügbaren URL-Daten einschränken aus dem Verweis-Header und document.referrer:

MDN bietet eine vollständige Liste aller Richtlinien und Verhaltensweisen, Beispiele.

Beachten Sie Folgendes, wenn Sie eine Referrer-URL-Richtlinie festlegen:

• Alle Richtlinien, die das Schema (HTTPS oder HTTP) berücksichtigen (strict-origin, no-referrer-when-downgrade und strict-origin-when-cross-origin), werden Anfragen von einem HTTP-Ursprung eines anderen HTTP-Ursprungs auf dieselbe Weise wie Anfragen von einem HTTPS-Ursprung an einen anderen HTTPS-Ursprung, obwohl HTTP weniger sicher ist. Das liegt daran, ist es wichtig, ob ein Sicherheits-Downgrade stattfindet, das Ist, wenn die Anfrage Daten aus einem verschlüsselten Ursprung an einen unverschlüsselten Ursprung weitergeben kann wie bei HTTPS → HTTP-Anfragen. Eine HTTP-→-HTTP-Anfrage ist vollständig unverschlüsselt und es gibt kein Downgrade.
• Wenn eine Anfrage same-origin ist, bedeutet dies, dass das Schema (HTTPS oder HTTP) ist dies gleich. Es gibt also kein Sicherheits-Downgrade.

Standardrichtlinien für Verweis-URLs in Browsern

Stand: Oktober 2021

Wenn keine Verweisrichtlinie festgelegt ist, verwendet der Browser seine Standardrichtlinie.

Best Practices zum Festlegen der Referrer-URL-Richtlinie

Es gibt verschiedene Möglichkeiten, Richtlinien für Verweis-URLs für Ihre Website festzulegen:

• Als HTTP-Header
• Im HTML-Datei
• Über JavaScript auf Anfragebasis

Sie können für verschiedene Seiten, Anfragen oder Elemente unterschiedliche Richtlinien festlegen.

Der HTTP-Header und das Meta-Element befinden sich beide auf Seitenebene. Die Reihenfolge der Prioritäten Die effektive Richtlinie eines Elements wird wie folgt bestimmt:

1. Richtlinie auf Elementebene
2. Richtlinie auf Seitenebene
3. Standardbrowser

Beispiel:

index.html:

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

Das Bild wird mit der Richtlinie no-referrer-when-downgrade angefordert und alle anderen Anfragen von Unterressourcen von dieser Seite folgen dem strict-origin-when-cross-origin .

So rufen Sie die Verweisrichtlinie auf

securityheaders.com ist nützlich, die eine bestimmte Website oder Seite verwendet.

Sie können auch die Entwicklertools in Chrome, Edge oder Firefox verwenden. Verweis-URL-Richtlinie, die für eine bestimmte Anfrage verwendet wird. Zum Zeitpunkt der Entstehung dieses Artikels zeigt nicht den Header „Referrer-Policy“ an, zeigt aber die „Referer“ an, die zuvor gesendet.

</ph> <ph type="x-smartling-placeholder">

Welche Richtlinie sollten Sie für Ihre Website festlegen?

Wir empfehlen dringend, ausdrücklich eine datenschutzfreundliche Richtlinie zu erstellen, z. B. strict-origin-when-cross-origin (oder strenger).

Warum „explizit“?

Wenn Sie keine Verweisrichtlinie festlegen, kommt die Standardrichtlinie des Browsers zum Einsatz. des Browsers auf die Standardeinstellungen des Browsers anwenden. Dies ist jedoch aus folgenden Gründen nicht ideal:

• Für jeden Browser gibt es unterschiedliche Standardrichtlinien. Standardeinstellungen ändert sich das Verhalten Ihrer Website bei verschiedenen Browsern nicht vorhersehbar.
• Browser verwenden strengere Standardeinstellungen wie strict-origin-when-cross-origin und Mechanismen wie z. B. Referrer-URL-Trimming. für ursprungsübergreifende Anfragen. Die ausdrückliche Zustimmung zu einer Richtlinie zur Verbesserung des Datenschutzes vor der Änderung der Standardeinstellungen des Browsers gibt Ihnen Kontrolle und können Tests durchführen, die Sie für angebracht halten.

Warum strict-origin-when-cross-origin (oder strenger)?

Sie benötigen eine Richtlinie, die sicher, datenschutzfreundlich und nützlich ist. Was „nützlich“ ist hängt davon ab, was Sie von der Referrer-URL erwarten:

• Sicher: Wenn Ihre Website HTTPS verwendet, sollten Sie sie als Priorität haben, möchten Sie nicht, dass die URLs Ihrer Website Nicht-HTTPS-Anfragen Da jeder im Netzwerk diese Daten sehen kann, und Ihre Nutzer einem „Person-in-the-Middle“-Angriff aussetzen. Richtlinien no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer und strict-origin lösen dieses Problem.
• Datenschutz verbessern: no-referrer-when-downgrade für eine ursprungsübergreifende Anfrage die vollständige URL weitergibt, was zu Datenschutzproblemen führen kann. strict-origin-when-cross-origin und strict-origin teilen nur den Ursprung, und no-referrer hat überhaupt keine Inhalte geteilt. Dadurch haben Sie strict-origin-when-cross-origin, strict-origin und no-referrer als datenschutzfreundliche Optionen nutzen.
• Nützlich: no-referrer und strict-origin teilen niemals die vollständige URL, auch nicht für Same-Origin-Anfragen. Wenn Sie die vollständige URL benötigen, strict-origin-when-cross-origin. ist die bessere Option.

All dies bedeutet, dass strict-origin-when-cross-origin in der Regel ein eine vernünftige Entscheidung.

Beispiel: Richtlinie „strict-origin-when-cross-origin“ festlegen

index.html:

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

Oder serverseitig, z. B. in Express:

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

Was ist, wenn strict-origin-when-cross-origin (oder ein strikterer Modus) nicht alle Ihre Anwendungsfälle unterstützt?

Ergreifen Sie in diesem Fall einen progressiven Ansatz: Legen Sie eine Schutzrichtlinie fest, z. B. strict-origin-when-cross-origin für Ihre Website. Bei Bedarf können Sie nicht zulässige Richtlinie für bestimmte Anfragen oder HTML-Elemente.

Beispiel: Richtlinie auf Elementebene

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 deckt möglicherweise document.referrer oder den Header Referer für websiteübergreifenden Anfragen. Siehe Details.

Beispiel: Richtlinie auf Anfrageebene

script.js:

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

Was sollten Sie noch beachten?

Ihre Richtlinien sollten von Ihrer Website und von Ihren Anwendungsfällen abhängig sein. Ihr Team und Ihr Unternehmen. Wenn einige URLs personenidentifizierbare oder sensible Daten enthalten, Schutzrichtlinie festlegen.

Best Practices für eingehende Anfragen

Im Folgenden finden Sie einige Richtlinien, wie Sie vorgehen sollten, wenn Ihre Website die Referrer-URL von eingehende Anfragen.

Nutzer schützen Daten

Referer kann private, personenbezogene oder personenidentifizierbare Daten enthalten. Achte daher darauf, behandeln Sie sie als solche.

Eingehende Verweis-URLs können {referer-can-change} ändern.

Die Verwendung der Referrer-URL von eingehenden ursprungsübergreifenden Anfragen unterliegt einigen Einschränkungen:

• Wenn Sie keine Kontrolle über die Implementierung des Anfrage-Emitters haben, können Sie Annahmen über den Referer-Header (und document.referrer), den Sie empfangen werden. Der Absender der Anfrage könnte zu einer no-referrer-Richtlinie wechseln oder generell strenger als die Richtlinien an, verwendet wurden. Das bedeutet, dass du weniger Daten vom Referer erhältst als zuvor.
• Browser verwenden zunehmend die Verweisrichtlinie strict-origin-when-cross-origin ist standardmäßig aktiviert. Dies bedeutet, dass Sie jetzt möglicherweise nur den Ursprung anstelle von eine vollständige Verweis-URL, in eingehenden ursprungsübergreifenden Anfragen, wenn die Website des Absenders keine Richtlinie festgelegt ist.
• Browser ändern möglicherweise die Art und Weise, wie sie Referer verwalten. Einige Browser haben z. B. Entwickelnde beschließen, Verweis-URLs immer auf Ursprünge in ursprungsübergreifenden für Unterressourcenanfragen verwendet, um die Privatsphäre der Nutzer zu schützen.
• Der Referer-Header (und document.referrer) können mehr Daten enthalten als die Sie brauchen. Sie könnte beispielsweise eine vollständige URL haben, wenn Sie nur wissen möchten, Die Anfrage ist ursprungsübergreifend.

Alternativen zu Referer

In folgenden Fällen müssen Sie möglicherweise Alternativen in Betracht ziehen:

• Eine wichtige Funktion Ihrer Website verwendet die Verweis-URL der eingehenden ursprungsübergreifenden Anfragen.
• Ihre Website erhält nicht mehr den Teil der Referrer-URL, den sie in einem ursprungsübergreifende Anfrage senden. Dies geschieht, wenn der Anfrage-Emitter seine oder wenn keine Richtlinie festgelegt ist und die Standardrichtlinie des Browsers geändert wurde (wie in Chrome 85).

Um Alternativen zu definieren, analysieren Sie zunächst, welchen Teil der Referrer-URL Sie verwenden.

Wenn Sie nur den Ursprung benötigen

• Wenn Sie die Verweis-URL in einem Skript verwenden, das Zugriff auf oberster Ebene auf der Seite hat, window.location.origin ist eine Alternative.
• Falls verfügbar, können Überschriften wie Origin und Sec-Fetch-Site erhalten Sie entweder die Origin oder geben an, ob die Anfrage ursprungsübergreifend ist, was genau das ist, was Sie brauchen.

Wenn Sie weitere Elemente der URL benötigen (Pfad, Suchparameter usw.),

• Anfrageparameter können sich auf Ihren Anwendungsfall beziehen, was Ihnen Referrer-URL geparst.
• Wenn Sie die Verweis-URL in einem Skript verwenden, das über oberster Ebene Zugriff auf die Seite hat, Als Alternative kann window.location.pathname verwendet werden. Nur den Pfad extrahieren der URL und als Argument übergeben, sodass alle möglicherweise sensiblen in den URL-Parametern nicht weitergegeben werden.

Falls Ihnen diese Alternativen nicht zur Verfügung stehen:

• Prüfen Sie, ob Sie Ihre Systeme so ändern können, dass der Absender der Anfrage erwartet wird (z. B. site-one.example), um die benötigten Informationen explizit festzulegen in irgendeiner Form konfiguriert.
  • Pro: Expliziter, datenschutzfreundlicher für site-one.example-Nutzer, zukunftssicherer machen.
  • Nachteil: Möglicherweise mehr Arbeit von Ihrer Seite oder für die Nutzer Ihres Systems.
• Überprüfen Sie, ob die Website, die die Anfragen ausgibt, möglicherweise einer Verweisrichtlinie pro Element oder pro Anfrage von no-referrer-when-downgrade
  • Nachteil: möglicherweise weniger datenschutzfreundlich für site-one.example-Nutzer, nicht in allen Browsern unterstützt.

CSRF-Schutz (Cross-Site Request Forgery)

Ein Anfrage-Emitter kann jederzeit entscheiden, die Referrer-URL nicht zu senden, indem ein no-referrer gesetzt ist, und ein böswilliger Akteur könnte die Referrer-URL sogar fälschen.

CSRF-Tokens verwenden als primären Schutz. Für zusätzlichen Schutz verwenden Sie SameSite und statt Referer verwenden Sie Header wie Origin (verfügbar für POST- und CORS-Anfragen) und Sec-Fetch-Site falls verfügbar.

Protokollieren und debuggen

Schützen Sie die personenbezogene oder sensible Daten, Referer

Wenn Sie nur den Ursprung verwenden, prüfen Sie, ob Sie den Origin-Header als eine Alternative sein. So erhalten Sie möglicherweise die Informationen, die Sie für die Fehlerbehebung benötigen vereinfacht und ohne die Referrer-URL parsen zu müssen.

Zahlungen

Zahlungsanbieter verlassen sich möglicherweise auf den Referer-Header eingehender Anfragen für Sicherheitsüberprüfungen durchführen.

Beispiel:

• Der Nutzer klickt auf online-shop.example/cart/checkout auf die Schaltfläche Kaufen.
• online-shop.example leitet zu payment-provider.example weiter, um Folgendes zu verwalten: Transaktion.
• payment-provider.example gleicht die Referer dieser Anfrage mit einer Liste ab der von den Händlern eingerichteten zulässigen Referer-Werten. Wenn es keine in der Liste enthält, lehnt payment-provider.example die Anfrage ab. Falls ja, kann der Nutzer mit der Transaktion fortfahren.

Best Practices für Sicherheitsprüfungen des Zahlungsflusses

Als Zahlungsdienstleister kannst du die Referer als grundlegenden Scheck gegen einige . Der Referer-Header allein ist jedoch keine zuverlässige Grundlage für einen Scheck. Die anfragende Website kann unabhängig davon, ob es sich um einen legitimen Händler handelt oder nicht, einen no-referrer-Richtlinie, die die Referer-Informationen für den Zahlungsdienstleister

Ein Blick auf die Referer könnte Zahlungsdienstleistern dabei helfen, naive Angreifer abzufangen, die hat keine no-referrer-Richtlinie festgelegt. Wenn Sie die Referer als erste Prüfung verwenden:

• Erwarte nicht, dass Referer immer vorhanden ist. Falls vorhanden, klicken Sie auf das Kästchen nur die geringstmöglichen Daten vergleichen, d. h. den Ursprung.
  • Wenn Sie die Liste der zulässigen Referer-Werte festlegen, dürfen Sie nur den Ursprung und keinen Pfad.
  • Die zulässigen Referer-Werte für online-shop.example sollten beispielsweise online-shop.example, nicht online-shop.example/cart/checkout. Indem erwartet wird, entweder gar kein Referer oder einen Referer-Wert, der nur der anfragende Wert ist verhindern Sie Fehler, die aus Vermutungen entstehen. zum Referrer-Policy des Händlers.
• Wenn Referer nicht vorhanden ist oder vorhanden ist und Ihr grundlegender Referer-Ursprung festgelegt ist ob die Prüfung erfolgreich ist, können Sie mit einer anderen, zuverlässigeren .

Für eine zuverlässigere Überprüfung von Zahlungen lassen Sie den Antragsteller Hashen Sie die Anfrageparameter mit einem eindeutigen Schlüssel. Zahlungsdienstleister können dann auf Ihrer Seite denselben Hashwert berechnen. und akzeptieren Sie die Anfrage nur, wenn sie Ihrer Berechnung entspricht.

Was passiert mit dem Referer, wenn eine HTTP-Händlerwebsite ohne Referrer-URL angezeigt wird? an einen HTTPS-Zahlungsanbieter weiterleitet?

In der Anfrage an den HTTPS-Zahlungsanbieter ist keine Referer sichtbar, weil Für die meisten Browser wird strict-origin-when-cross-origin oder Standardmäßig no-referrer-when-downgrade, wenn für eine Website keine Richtlinien festgelegt sind. Neue Standardrichtlinie für Chrome ändert sich nichts daran.

Fazit

Eine schützende Richtlinie für Referrer-URLs ist eine hervorragende Möglichkeit, den Datenschutz für Ihre Nutzer zu erhöhen.

Wenn du mehr über die verschiedenen Techniken zum Schutz deiner Nutzer erfahren möchtest, besuche unsere Sichere Erfassung

Ressourcen

• Funktionsweise von „same-site“ und „same-origin“
• Ein neuer Sicherheitsheader: Referrer-URL-Richtlinie (2017)
• Richtlinie für Referrer-URL aktiviert MDN
• Verweis-Header: Bedenken im Hinblick auf Datenschutz und Sicherheit auf MDN
• Änderung in Chrome: Zwinkern mit implementieren
• Änderung in Chrome: Zwinkern mit Schiff
• Chrome-Änderung: Statuseintrag
• Chrome-Änderung: Version 85 (Beta) blogpost
• Referrer-URL-Trennung von GitHub-Thread: welche Browser Das solltest du tun
• Spezifikation der Verweisrichtlinie

Vielen Dank für die Beiträge und das Feedback an alle Prüfer – insbesondere an KauStubha Govind. David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck und Kayce Basques.