Referer-Header: Datenschutz- und Sicherheitsbedenken

Das Referrer-Problem

Der Referer-Header (sic) enthält die Adresse einer Anfrage (zum Beispiel die Adresse der vorherigen Webseite, von der aus ein Link zur aktuell angeforderten Seite gefolgt wurde, oder die Adresse einer Seite, die ein Bild oder eine andere Ressource lädt). Dies hat viele relativ harmlose Anwendungen, einschließlich Analytik, Protokollierung oder optimiertes Caching. Es gibt jedoch problematischere Anwendungen wie das Verfolgen oder Stehlen von Informationen oder auch nur Nebenwirkungen wie das unabsichtliche Offenlegen sensibler Informationen.

Betrachten Sie zum Beispiel eine "Passwort zurücksetzen"-Seite mit einem sozialen Medienlink im Footer. Wenn der Link gefolgt wurde, könnte die Seite der sozialen Medien, je nachdem, wie Informationen geteilt wurden, die URL zum Zurücksetzen des Passworts erhalten und möglicherweise immer noch in der Lage sein, die geteilten Informationen zu nutzen, was die Sicherheit eines Nutzers gefährden könnte.

Nach demselben Prinzip könnte ein Bild einer Drittanbieterseite, das in Ihre Seite eingebettet ist, dazu führen, dass sensible Informationen an den Drittanbieter weitergegeben werden. Selbst wenn die Sicherheit nicht gefährdet ist, möchten die Nutzer möglicherweise nicht, dass diese Informationen geteilt werden.

Wie können wir das beheben?

Ein Großteil dieses Risikos kann durch eine sinnvolle Gestaltung von Anwendungen gemindert werden. Eine sinnvolle Anwendung würde solche Risiken eliminieren, indem sie URLs zum Zurücksetzen des Passworts einmalig verwendet oder sie mit einem einzigartigen Benutzertoken kombiniert. Das Risiko kann auch verringert werden, indem sensible Daten auf sicherere Weise übertragen werden.

Sie sollten POST anstelle von GET verwenden, wann immer dies möglich ist, um zu vermeiden, dass sensible Daten über URLs an andere Orte übermittelt 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 Rat ist weniger relevant, da ein Großteil des Webs jetzt HTTPS verwendet, aber es ist immer noch eine Überlegung wert.

Darüber hinaus sollten Sie in Betracht ziehen, jeglichen Drittanbieterinhalt (z. B. soziale Netzwerk-Widgets, die in <iframe> eingebettet sind) aus sicheren Bereichen Ihrer Website zu entfernen, wie Passwort-Zurücksetzen-Seiten, Zahlungsformulare, Login-Bereiche usw.

Sie können solche Risiken auch mindern, indem Sie:

• Den Referrer-Policy-Header auf Ihrem Server verwenden, um zu steuern, 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 auf HTML-Elementen, die Gefahr laufen, solche Informationen preiszugeben (wie <img> und <a>). Dies kann beispielsweise auf no-referrer gesetzt werden, um zu verhindern, dass der Referer-Header überhaupt gesendet wird.
• Das rel-Attribut, das auf noreferrer gesetzt wird, bei HTML-Elementen, die Gefahr laufen, solche Informationen preiszugeben (wie <form> und <a>).
• Ein <meta>-Element mit einem name von referrer und der Inhalt auf no-referrer gesetzt, um den Referer-Header für das gesamte Dokument zu deaktivieren. Siehe Referrer-Policy Integration with HTML.
• Die Exit page-Technik.

Sicherheitsbewusste serverseitige Frameworks neigen dazu, eingebaute Maßnahmen gegen solche Probleme zu haben, zum Beispiel:

• Sicherheit in Django (besonders beachten Sie den Abschnitt Schutz vor Cross-Site Request Forgery (CSRF)).
• Helmet referrer-policy — Middleware zum Setzen der Referrer-Policy in Node.js/Express-Apps (siehe auch Helmet für weitere Sicherheitsvorkehrungen).

Richtlinien und Anforderungen

Es wäre sinnvoll, eine Reihe von Sicherheits- und Datenschutzanforderungen für Ihre Projektteams 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 Wohlergehen der Nutzer als auch andere Themen wie die von Gesetzen auferlegten Richtlinien und Vorschriften, wie die EU-Datenschutz-Grundverordnung (GDPR), berücksichtigen.

Siehe auch

• Mozillas Sicherheitsrichtlinien zur Referrer-Policy