Fehlende Referrer-Policy

Der Referer-Header ist ein Überbleibsel aus der Anfangszeit des Webs, gedacht, um Websitebetreibern zu zeigen, woher ihre Besucher kamen. Diese gut gemeinte Funktion sendet heute standardmäßig die vollständige URL Ihrer Seite an jede externe Partei, die Ihr Besucher berührt. Im Folgenden lesen Sie, was darin stecken kann und wie Sie das begrenzen.

Was ist die Referrer-Policy?

Die Referrer-Policy ist ein HTTP-Header, mit dem Sie bestimmen, wie viel der Browser über die Seite preisgibt, von der eine Anfrage ausgeht. Ohne Richtlinie wenden Browser einen Standardwert an, der die vollständige URL innerhalb derselben Domain übergibt und nach außen die Domain; ältere Browser und manche Konfigurationen sind großzügiger und senden die komplette Adresse einschließlich Pfad und Abfrageparametern.

Stellen Sie sich einen Besucher vor, der beim Eintreten standardmäßig erzählt, woher er kommt. “Ich komme von der Website der Gemeinde” ist harmlos. “Ich komme von der Seite Passwort-Wiederherstellen mit Token 8f3a-c91d” ist es nicht. Der Header selbst unterscheidet nicht: Er gibt weiter, was in der URL steht.

Deshalb ist dieser Befund für sich genommen leicht, während seine tatsächliche Bedeutung vollständig davon abhängt, wie Ihre Anwendung ihre URLs aufbaut.

Wie gelangen Informationen über den Referrer nach außen?

Das Leck entsteht nicht nur, wenn ein Nutzer auf einen externen Link klickt. Jede Ressource, die die Seite lädt, ein Skript von einem CDN, eine Schriftart, ein Bild, ein Analyse-Pixel, erhält den Header ebenso.

Verwundbar:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

Es gibt keine Richtlinie, der Browser wendet also seinen Standard an. Betrachtet der Nutzer diese Seite:

https://portal.example/wiederherstellung?token=9c2f81ad4e&nutzer=j.walter@firma.de

und lädt diese Seite ein externes Skript oder klickt der Nutzer auf einen externen Link, geht Folgendes an diesen Dritten:

GET /widget.js HTTP/1.1
Host: cdn.example
Referer: https://portal.example/wiederherstellung?token=9c2f81ad4e&nutzer=j.walter@firma.de

Das Wiederherstellungstoken und die E-Mail-Adresse stehen nun in den Protokolldateien einer Partei, die damit nichts zu tun hat. Wer Zugriff auf diese Protokolle hat, ein Mitarbeiter, ein Angreifer, der das CDN kompromittiert, oder der Dienst selbst, kann mit diesem Token das Passwort dieses Nutzers neu setzen.

Sicher:

HTTP/1.1 200 OK
Referrer-Policy: strict-origin-when-cross-origin

Innerhalb Ihrer eigenen Domain bleibt die vollständige URL verfügbar, sodass interne Statistiken und Navigationslogik weiter funktionieren. Geht die Anfrage an eine andere Domain, wird nur https://portal.example übergeben, ohne Pfad und Parameter. Und geht sie an ein unverschlüsseltes Ziel, sendet der Browser gar nichts. Für Seiten, von denen wirklich nichts nach außen gelangen darf, gehen Sie einen Schritt weiter:

Referrer-Policy: no-referrer

Welche Auswirkungen hat eine fehlende Referrer-Policy?

Als eigenständiger Befund ist dies eine Härtungsfrage mit niedrigem Schweregrad: Ein unmittelbarer Angriff ist nicht möglich, und es gibt keine Schwachstelle in Ihrem Code. Die Bedeutung entsteht im Zusammenspiel mit der übrigen Anwendung.

Enthalten Ihre URLs ausschließlich neutrale Pfade, bleibt der Schaden beim Datenschutz: Externe Parteien sehen, welche Seiten Ihre Besucher betrachten, was bei einem medizinischen, juristischen oder finanziellen Dienst bereits sensibel genug sein kann. Stehen dort sehr wohl identifizierende Angaben oder Token, verschiebt sich das zu einem echten Sicherheitsproblem, denn diese Werte gelangen damit zu Dritten.

Es gibt noch eine weniger bekannte Verwendung: Ausgelaufene interne URL-Strukturen helfen einem Angreifer, Ihre Anwendung zu erfassen. Pfadnamen wie /verwaltung/berichte/exportieren verraten Funktionen, die sonst nicht sichtbar sind, und genau mit dieser Art von Information beginnt ein gezielter Angriff.

Wie spürt man eine fehlende Referrer-Policy auf?

Das Vorhandensein des Headers ist schnell festgestellt, doch die maßgebliche Frage lautet, was ohne Richtlinie nach außen gelangen würde. Ein Tester erfasst deshalb, welche URLs in der Anwendung Parameter enthalten und ob darin sensible Werte stehen: Token, E-Mail-Adressen, Kundennummern, Suchanfragen oder Dokumentkennungen.

Anschließend wird betrachtet, welche externen Quellen diese Seiten laden, denn jede davon ist ein Empfänger des Headers. Ebenso wird geprüft, ob die Richtlinie auf allen Routen einheitlich gesetzt ist; gerade die Wiederherstellungs- und Einladungsseiten, auf denen die sensibelsten URLs vorkommen, werden häufig gesondert behandelt und entbehren dann des Headers. AssistSec beurteilt die Verbindung aus beidem: nicht nur, ob der Header vorhanden ist, sondern vor allem, ob in Ihren URLs etwas steht, das nie nach außen gelangen durfte.

Wie verhindert man eine fehlende Referrer-Policy?

• Setzen Sie Referrer-Policy: strict-origin-when-cross-origin als zentrale Voreinstellung für die gesamte Anwendung.
• Verwenden Sie no-referrer auf Seiten, die Token, Wiederherstellungscodes oder personenbezogene Daten in der URL enthalten.
• Platzieren Sie Geheimnisse nie in einem Abfrageparameter; nutzen Sie einen POST-Body, einen Header oder eine kurzlebige serverseitige Sitzung.
• Ergänzen Sie rel="noreferrer" an Links zu externen Websites, deren Herkunft Sie nicht preisgeben möchten.
• Begrenzen Sie die Zahl der externen Quellen, die Ihre Seiten laden; jede davon ist ein Empfänger des Referrers.
• Prüfen Sie, ob auch Fehlerseiten, per E-Mail angesteuerte Landeseiten und Antworten aus einem CDN den Header mitsenden.
• Kombinieren Sie den Header mit einer Content Security Policy, damit Sie sowohl begrenzen, was lädt, als auch, was dabei übergeben wird.