Referrer-Policy: HTTP-Security-Header zum Schutz vor Informationsabfluss
In diesem Beitrag stelle ich euch den HTTP-Security-Header Referrer-Policy vor. Mit diesem Security-Header lässt sich steuern, wie viel bzw. welche Referrer-Informationen von eurer Website oder Webanwendung weitergegeben werden. Hierdurch lässt sich der häufig ungewollte Abfluss von Informationen, der ggf. mit Sicherheits- sowie Datenschutzrisiken einhergeht, vermeiden.
Was ist der Referrer?
Beim Referrer handelt es sich um die Webseite, genauer gesagt die URL, über die der Besucher zur aktuellen Webseite gelangt ist. Übermittelt wird diese Referrer-Information mittels dem Referer-HTTP-Header. Dieser wird im Header-Bereich einer HTTP-Anfrage vom Webbrowser zum Webserver mitgesendet. Die Übertragung des Referer-Headers ist optional, aber standardmäßig übertragen ihn alle gängigen Webbrowser. Ausnahme: Der Besucher gelangt von einer mittels HTTPS verschlüsselten auf eine unverschlüsselte mit HTTP ausgelieferte Webseite.
Beispiel einer HTTP-Anfrage mit Referer-Header
Angenommen ein Besucher befindet sich auf der Webseite:
https://domain1.de/auto.html
Auf dieser Webseite befindet sich ein Link, der auf folgende Webseite (URL) verweist:
https://domain2.de/katze.html
Klickt der Besucher nun auf diesen Link, sendet der Webbrowser des Besuchers folgende HTTP-Anfrage an den Webserver der verlinkten Webseite bzw. URL:
Welche Referrer-Informationen genau übertragen werden, hängt vom jeweiligen Webbrowser ab. Durch Webbrowser-Plugins oder der in diesem Beitrag vorgestellten Referrer-Policy lässt sich dies individuell einstellen.
Mögliche Sicherheits- und Datenschutzrisiken
Im Allgemeinen werden die vom Webserver erhaltenen Anfragedaten, die z.B. die angefragte URL, User-Agent, Referrer usw. enthalten, zu Logging- und Auswertungszwecken gespeichert. Betreiber von Webservern können die Daten theoretisch auf jede erdenkliche Art verarbeiten. Im Idealfall nutzen sie die Daten einfach nur zu unkritischen Zwecken, wie z.B. zur statistischen Auswertung, um ihre Website für ihre Besucher zu optimieren.
Es besteht allerdings auch die Möglichkeit, dass die Referrer-Informationen zum Tracking und zum Abgreifen von Daten missbraucht werden. Aus Datenschutzsicht könnten mittels dem Referrer ungewollt Informationen preisgegeben werden, die ggf. die Identifikation des Besuchers ermöglichen.
Beispiel: https://my-webapp-xyz.de/dashboard/mustermann
Ein weiteres denkbares sicherheitskritisches Szenario:
Ein Benutzer einer Webanwendung möchte sein Passwort zurücksetzen. Hierfür bieten Webanwendungen oftmals entsprechende Funktionen. Im Allgemeinen erhält der Benutzer dabei eine E-Mail mit einer Token-basierten generierten URL. Diese URL bzw. Webseite muss der Benutzer aufrufen, um dann sein Passwort zurückzusetzen. Befindet sich auf dieser "Passwort-Zurücksetzen"-Webseite nun ein Link zu einer externen Webseite und der Benutzer klickt auf den Link, wird die eigentlich nur dem Benutzer bekannte URL im Referrer mitgesendet. Für den Fall, dass die Webanwendung den Fall eines erneuten Aufruf der URL nicht korrekt handhabt, könnte ein Dritter nun die URL missbrauchen, um das Passwort des eigentlichen Benutzers zu ändern und sich ggf. Zugriff zum Benutzerkonto zu verschaffen.
Referrer-Policy - Beschreibung & Funktionsweise
Die anzuwendende Referrer-Policy wird dem Webbrowser vom Webserver innerhalb der HTTP-Antwort mittels dem Referrer-Policy-Header mitgeteilt:
Durch die im o.a. Beispiel angegebene Referrer-Policy wird der Webbrowser angewiesen keinerlei Referrer-Informationen weiterzugeben.
Im nächsten Abschnitt werden die unterstützten Policy-Direktiven beschrieben. Die Direktive der Referrer-Policy bestimmt, ob und wenn ja welche Referrer-Informationen für Anfragen, die von der aktuellen Webseite ausgelöst werden, vom Webbrowser in HTTP-Anfragen mitgesendet werden.
Policy-Direktiven im Detail
''
:
Hiermit wird dem Webbrowser mitgeteilt, dass die Referrer-Policy keine Anwendung findet und es dem Webbrowser überlassen ist, wie der Referrer ermittelt und weitergegeben wird.
no-referrer
:
Der Webbrowser wird angewiesen keinen Referer-Header und somit keinerlei Referrer-Informationen zu senden.
Quell-Webseite | Ziel-Webseite | Referrer |
---|---|---|
https://codingblatt.de/page1 | beliebig | (kein Referrer) |
no-referrer-when-downgrade
:
Bei dieser Direktive handelt es sich im Allgemeinen um die Standard-Einstellung der Webbrowser. Sobald von einer verschlüsselten HTTPS- auf eine unverschlüsselte HTTP-Verbindung navigiert wird, so überträgt der Webbrowser keinen Referrer.
Quell-Webseite | Ziel-Webseite | Referrer |
---|---|---|
https://codingblatt.de/page1 | http://codingblatt.de/page2 | (kein Referrer) |
https://codingblatt.de/page1 | https://codingblatt.de/page2 | https://codingblatt.de/page1 |
http://codingblatt.de/page1 | https://codingblatt.de/page2 | http://codingblatt.de/page1 |
https://codingblatt.de/page1 | https://mozilla.org/page1 | https://codingblatt.de/page1 |
same-origin
:
Der Referrer wird bei dieser Direktive nur bei Same-Origin-Policy-Anfragen gesetzt.
Quell-Webseite | Ziel-Webseite | Referrer |
---|---|---|
https://codingblatt.de/page1 | https://codingblatt.de/page2 | https://codingblatt.de/page1 |
https://codingblatt.de/page1 | http://codingblatt.de/page2 | (kein Referrer) |
https://codingblatt.de/page1 | https://mozilla.org/page1 | (kein Referrer) |
origin
:
Als Referrer-Information wird nur die Herkunft, die sogenannte Origin, vom Webbrowser weitergegeben. Pfad- und Query-Angaben sind im Referrer also nicht enthalten.
Quell-Webseite | Ziel-Webseite | Referrer |
---|---|---|
https://codingblatt.de/page1 | beliebig | https://codingblatt.de/ |
strict-origin
:
Analog zur origin
-Direktive nur mit der Ausnahme, dass beim Wechsel von einer verschlüsselten HTTPS- auf eine unverschlüsselte HTTP-Verbindung keine Referrer-Informationen übertragen werden.
Quell-Webseite | Ziel-Webseite | Referrer |
---|---|---|
https://codingblatt.de/page1 | https://codingblatt.de/page2 | https://codingblatt.de/ |
https://codingblatt.de/page1 | http://codingblatt.de/page2 | (kein Referrer) |
https://codingblatt.de/page1 | https://mozilla.org/page1 | https://codingblatt.de/ |
https://codingblatt.de/page1 | http://mozilla.org/page1 | (kein Referrer) |
origin-when-cross-origin
:
Als Referrer-Information wird die komplette URL weitergegeben, sofern die angefragte Webseite bzw. Ressource gleicher Herkunft ist, andernfalls wird nur die Origin gesetzt.
Quell-Webseite | Ziel-Webseite | Referrer |
---|---|---|
https://codingblatt.de/page1 | https://codingblatt.de/page2 | https://codingblatt.de/page1 |
https://codingblatt.de/page1 | http://codingblatt.de/page2 | https://codingblatt.de/ |
https://codingblatt.de/page1 | https://mozilla.org/page1 | https://codingblatt.de/ |
strict-origin-when-cross-origin
:
Kombination aus den Direktiven strict-origin
und origin-when-cross-origin
.
Quell-Webseite | Ziel-Webseite | Referrer |
---|---|---|
https://codingblatt.de/page1 | https://codingblatt.de/page2 | https://codingblatt.de/page1 |
https://codingblatt.de/page1 | http://codingblatt.de/page2 | (kein Referrer) |
https://codingblatt.de/page1 | https://mozilla.org/page1 | https://codingblatt.de/ |
https://codingblatt.de/page1 | http://mozilla.org/page1 | (kein Referrer) |
unsafe-url
:
Damit wird der Webbrowser angewiesen immer die kompletten Referrer-Informationen, unabhängig der Verbindungsart und der Herkunft, mitzusenden.
Quell-Webseite | Ziel-Webseite | Referrer |
---|---|---|
https://codingblatt.de/page1 | beliebig | https://codingblatt.de/page1 |
Webbrowser-Unterstützung
Die Unterstützung der Referrer-Policy ist in allen moderen Webbrowser gegeben: siehe hierzu auch caniuse.com
Referrer-Policy übertragen
Damit der Webserver die Referrer-Policy zum Webbrowser innerhalb von HTTP-Antworten als Referrer-Policy-Header mitsendet, muss dieser entsprechend konfiguriert werden.
Apache:
In der Apache-Konfigurationsdatei bzw. alternativ in der entsprechenden .htaccess
fügt ihr folgende Zeile hinzu:
nginx:
Die nginx-Konfigurationsdatei ist wie folgt zu erweitern:
Alternative Möglichkeiten zur Übertragung
Neben der empfohlenen Übertragungsweise per HTTP-Header, kann die Referrer-Policy alternativ auch direkt im HTML-Quellcode angegeben werden.
Zum einen besteht die Option ein entsprechendes meta
-Element zu setzen:
Zum anderen lässt sich für ein a
-Element individuell eine Referrer-Policy definieren.
Referrer-Policy von codingblatt.de
Für dieses Blog verwende ich die Policy bzw. Direktive no-referrer
. Es werden also keinerlei Referrer-Informationen an Dritte übermittelt.
Fazit
Mittels der Referrer-Policy ist es ohne großen Aufwand möglich Sicherheit und Datenschutz eurer Website bzw. Webanwendung zu verbessern. Ich persönlich würde euch empfehlen, die Referrer-Policy, unter Berücksichtigung eurer individuellen Anforderungen, so restriktiv wie möglich einzustellen.
- 4. Juli 2020
Bereich "Referrer-Policy von codingblatt.de" angepasst - anstattstrict-origin-when-cross-origin
verwende ich nun hier im Blogno-referrer