Referer-Header: Datenschutz- und Sicherheitsbedenken

Es gibt Datenschutz- und Sicherheitsrisiken im Zusammenhang mit dem Referer HTTP-Header. Dieser Artikel beschreibt sie und bietet Ratschläge zur Minderung dieser Risiken.

Das Referrer-Problem

Der Referer-Header (sic) enthält die Adresse einer Anfrage (zum Beispiel die Adresse der vorhergehenden Webseite, von der aus ein Link zur derzeit angeforderten Seite gefolgt wurde, oder die Adresse einer Seite, die ein Bild oder eine andere Ressource lädt). Dies hat viele recht harmlose Verwendungen, einschließlich Analytik, Protokollierung oder optimiertes Caching. Allerdings gibt es problematischere Verwendungen wie Tracking oder das Stehlen von Informationen oder sogar nur Nebeneffekte wie das versehentliche Offenlegen sensibler Informationen.

Betrachten Sie beispielsweise eine "Passwort zurücksetzen"-Seite mit einem Social-Media-Link im Footer. Wenn dem Link gefolgt wurde, könnte die Social-Media-Seite, abhängig davon, wie Informationen geteilt wurden, die URL zum Zurücksetzen des Passworts erhalten und die geteilten Informationen möglicherweise weiterhin nutzen, was die Sicherheit eines Benutzers gefährden könnte.

Nach demselben Prinzip könnte ein Bild von einer Drittanbieter-Website, das auf Ihrer Seite eingebettet ist, dazu führen, dass sensible Informationen an den Drittanbieter preisgegeben werden. Selbst wenn die Sicherheit nicht gefährdet ist, sind die Informationen möglicherweise nicht etwas, das der Benutzer teilen möchte.

Wie können wir das beheben?

Ein Großteil dieses Risikos kann durch eine vernünftige Gestaltung von Anwendungen gemindert werden. Eine sinnvolle Anwendung würde solche Risiken durch einmalig verwendbare URLs zum Zurücksetzen des Passworts beseitigen oder sie mit einem eindeutigen Benutzertoken kombinieren. Das Risiko kann auch durch die Übertragung sensibler Daten auf sicherere Weise reduziert werden.

Sie sollten POST anstelle von GET verwenden, wann immer möglich, um zu vermeiden, dass sensible Daten über URLs an andere Standorte weitergegeben werden.

Sie sollten immer HTTPS für Ihre Seiten verwenden. Dies hat viele Sicherheitsvorteile, einschließlich der Tatsache, dass HTTPS-Seiten niemals Referrer-Informationen an nicht-HTTPS-Seiten übertragen. Dieser Ratschlag ist weniger relevant, da der Großteil des Webs mittlerweile HTTPS verwendet, aber es ist dennoch eine Überlegung wert.

Darüber hinaus sollten Sie erwägen, jegliche Inhalte von Drittanbietern (z. B. in <iframe> eingebettete Social-Networking-Widgets) von sicheren Bereichen Ihrer Website zu entfernen, wie z. B. Passwort-Zurücksetzungsseiten, Zahlungsformulare, Anmeldebereiche usw.

Sie können solche Risiken auch mithilfe der folgenden Methoden mindern:

  • Der Referrer-Policy-Header auf Ihrem Server, um zu kontrollieren, welche Informationen über den Referer-Header gesendet werden. Zum Beispiel würde eine Direktive von no-referrer den Referer-Header vollständig weglassen.
  • Das referrerpolicy-Attribut in HTML-Elementen, die Gefahr laufen, solche Informationen zu leaken (wie <img> und <a>). Dieses kann zum Beispiel auf no-referrer gesetzt werden, um das Senden des Referer-Headers insgesamt zu stoppen.
  • Das rel-Attribut auf noreferrer in HTML-Elementen, die Gefahr laufen, solche Informationen zu leaken (wie <form> und <a>).
  • Ein <meta>-Element mit einem name von referrer und dem Inhalt auf no-referrer gesetzt, um den Referer-Header für das gesamte Dokument zu deaktivieren. Siehe Referer-Richtlinien-Integration mit HTML.
  • Die Exit-Seiten-Technik.

Sicherheitsbewusste serverseitige Frameworks neigen dazu, eingebaute Milderungen für solche Probleme zu haben, zum Beispiel:

Richtlinien und Anforderungen

Es wäre sinnvoll, für Ihr(e) Projektteam(s) eine Reihe von Sicherheits- und Datenschutzanforderungen zu schreiben, die die Nutzung solcher Funktionen zur Minderung der damit verbundenen Risiken spezifizieren. Sie sollten die Hilfe eines Web-Sicherheitsexperten in Anspruch nehmen, um diese Anforderungen zu schreiben, und sowohl die Bedürfnisse und das Wohlbefinden der Benutzer als auch andere Fragen wie Richtlinien und Vorschriften berücksichtigen, die durch Gesetze wie die EU-Datenschutz-Grundverordnung (DSGVO) durchgesetzt werden.

Siehe auch