#!/coding/blatt
Sammelsurium mit Schwerpunkten Linux & IT-Sicherheit

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.

Anmerkung Schreibweise Referer vs Referrer

Die korrekte Schreibweise lautet Referrer. Im ursprünglichen RFC 2068 wurde fälschlicherweise die Schreibweise Referer verwendet.

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:

GET /katze.html HTTP/1.1
Host: domain2.de
Referer: https://domain1.de/auto.html
HTTP-GET-Anfrage mit Referer-Header

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:

HTTP/2 200 OK
date: Sun, 15 Mar 2020 14:30:45 GMT
content-type: text/html; charset=UTF-8
content-length: 2802
referrer-policy: no-referrer
HTTP-Antwort mit Referrer-Policy-Header

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-WebseiteZiel-WebseiteReferrer
https://codingblatt.de/page1beliebig(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-WebseiteZiel-WebseiteReferrer
https://codingblatt.de/page1http://codingblatt.de/page2(kein Referrer)
https://codingblatt.de/page1https://codingblatt.de/page2https://codingblatt.de/page1
http://codingblatt.de/page1https://codingblatt.de/page2http://codingblatt.de/page1
https://codingblatt.de/page1https://mozilla.org/page1https://codingblatt.de/page1

same-origin:
Der Referrer wird bei dieser Direktive nur bei Same-Origin-Policy-Anfragen gesetzt.

Quell-WebseiteZiel-WebseiteReferrer
https://codingblatt.de/page1https://codingblatt.de/page2https://codingblatt.de/page1
https://codingblatt.de/page1http://codingblatt.de/page2(kein Referrer)
https://codingblatt.de/page1https://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-WebseiteZiel-WebseiteReferrer
https://codingblatt.de/page1beliebighttps://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-WebseiteZiel-WebseiteReferrer
https://codingblatt.de/page1https://codingblatt.de/page2https://codingblatt.de/
https://codingblatt.de/page1http://codingblatt.de/page2(kein Referrer)
https://codingblatt.de/page1https://mozilla.org/page1https://codingblatt.de/
https://codingblatt.de/page1http://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-WebseiteZiel-WebseiteReferrer
https://codingblatt.de/page1https://codingblatt.de/page2https://codingblatt.de/page1
https://codingblatt.de/page1http://codingblatt.de/page2https://codingblatt.de/
https://codingblatt.de/page1https://mozilla.org/page1https://codingblatt.de/

strict-origin-when-cross-origin:
Kombination aus den Direktiven strict-origin und origin-when-cross-origin.

Quell-WebseiteZiel-WebseiteReferrer
https://codingblatt.de/page1https://codingblatt.de/page2https://codingblatt.de/page1
https://codingblatt.de/page1http://codingblatt.de/page2(kein Referrer)
https://codingblatt.de/page1https://mozilla.org/page1https://codingblatt.de/
https://codingblatt.de/page1http://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-WebseiteZiel-WebseiteReferrer
https://codingblatt.de/page1beliebighttps://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:

Header set Referrer-Policy "same-origin"
Apache-Konfigurationsdatei bzw. .htacess

nginx:
Die nginx-Konfigurationsdatei ist wie folgt zu erweitern:

add_header Referrer-Policy same-origin;
nginx-Konfigurationsdatei

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:

<meta name="referrer" content="same-origin"/>
HTML - Referrer-Policy per meta-Element

Zum anderen lässt sich für ein a-Element individuell eine Referrer-Policy definieren.

<a href="https://www.codingblatt.de/page2" referrerpolicy="same-origin">Seite 2</a>
HTML - Referrer-Policy per a-Element

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.

Aktualisierungshistorie:
  • 4. Juli 2020
    Bereich "Referrer-Policy von codingblatt.de" angepasst - anstatt strict-origin-when-cross-origin verwende ich nun hier im Blog no-referrer