The HTTP Referer header was defined to determine the origin of a user’s request on the server side. As such, today’s web browsers use this header to communicate the last visited resource when requesting a new one. Since it is often written to a server’s access log, the header may be evaluated or used for other purposes. This may result in security issues. The author describes the problem and provides simple solutions. The article is available in German.
Obwohl der HTTP Referer Header gemäss Standard [1] optional ist, wird er aktuell von allen gängigen Browsern übermittelt. Die dabei übermittelte URL hingegen ist nicht immer für die Öffentlichkeit beabsichtigt und kann in diversen Fällen zu Datenschutz- sowie Privatsphärenproblemen führen.
Es gibt viele Webdienste, welche Informationen nur durch eine generierte und nicht veröffentlichte URL schützen. Dazu gehören beispielsweise Webseiten zur Nachverfolgung und Zustellung von Briefen oder Paketen, Bestellungs- und Buchungsbestätigungen oder Plattformen für Datenaustausch. Daneben sind auch häufig benutzerspezifische Informationen, wie Benutzername, Benutzernummern, Adressen, Session Tokens oder zeitlich beschränkte Authentifizierungstoken in der URL zu finden. Auch ist es möglich, dass dadurch Adressen von Intranet Webseiten ins Internet gelangen. Da eine solche URL sehr häufig durch den Referer Header an Dritte weitergegeben wird, führt dies zu Sicherheitsproblemen. Werden diese Daten beispielsweise nicht genügend geschützt, kann ein Angreifer unter Umständen eine Session übernehmen oder auf geschützte Ressourcen zugreifen.
Vor allem in Fällen, bei welchen schützenwerte Personendaten im Spiel sind, zum Beispiel im Banken- oder Gesundheitsbereich, ist grosse Vorsicht geboten. Da es sich bei der IP-Adresse um eine personenidentifizierende Information handelt, kann eine Kundenbeziehung bereits durch das Erhalten eines Referer Headers festgestellt werden. Der Header könnte eine URL zu einem via Authentifizierungsmechanismus geschützten Kundenbereich beinhalten, wodurch einfach festgestellt werden kann, dass der aktuelle Benutzer ein registrierter Nutzer der zugehörigen Webseite ist.
Sobald eine Webseite externen Inhalt darstellt oder ein Besucher einen externen Link auf der Webseite öffnet, wird die aktuelle URL, durch den Referer Header an den entsprechenden Provider gesendet. Dies findet auch statt, wenn es sich bei der Zielseite um eine andere Domain handelt. Grundsätzlich wird der Header immer mitgesendet, ausser wenn von einer sicheren HTTPS Verbindung auf eine unsichere HTTP Verbindung gewechselt wird. Es können bereits die folgenden sehr häufig verwendeten Funktionen zu einem problematischen Sicherheitsrisiko oder zum nicht Einhalten von regulatorischen Bestimmungen führen:
- Links zu externen Webseiten
- Tracking Dienste (Google Analytics, Adobe Web Analytics)
- Social Media Integration (Facebook Like Button, Twitter Button)
- Sonstige externe Ressourcen wie JavaScript Dateien, Bilder, Videos
Folgende Beispiele zeigen auf, wie eine URL als Referer Header weitergeleitet wird:
Wird auf einer Webseite auf einen Facebook Link geklickt, so wird die aktuelle URL als Referer Header an Facebook weitergeleitet.
GET / HTTP/1.1
Host: www.facebook.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Referer: https://mysite.com/myaccount.html?sessionid=9843629805234
Connection: close
Die gleiche URL könnte bereits vorher durch das integrierte Google Analytics Framework an Google übermittelt werden.
GET /analytics.js HTTP/1.1
Host: www.google-analytics.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Referer: https://mysite.com/myaccount.html?sessionid=9843629805234
Connection: close
Durch das Einbinden eines Facebook Like Buttons oder Twitter Funktionen wird die URL auch automatisch ohne Benutzerinteraktion an den entsprechenden Dienstprovider weitergeleitet.
GET /impression.php/f38f6dffe14ff64/?lid=115&payload=%7B%22source%22%3A%22jssdk%22%7D HTTP/1.1
Host: www.facebook.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Referer: https://mysite.com/myaccount.html?sessionid=9843629805234
Connection: close
Gegenmassnahmen
Grundsätzlich sollten in der URL nie schützenswerte Informationen verborgen sein. Das Risiko kann weiter minimiert werden, indem kein externer Inhalt auf der Webseite angezeigt wird und Links zu anderen Webseiten sich nur auf Seiten befinden, bei welchen die URL keine Informationen preisgibt.
Clientseitig kann der HTTP Referer Header teilweise im Browser deaktiviert werden. Um effektive Sicherheit zu gewährleisten müssten jedoch alle Webseitenbesucher dies umsetzen, was in der Praxis nicht realistisch ist.
Serverseitig lässt sich der HTTP Referer Header durch die «Referrer Policy» anpassen. Dabei handelt es sich um einen Draft-Standard der unter [3] beschrieben ist. Er wird von aktuellen Browsern wie Firefox, Chrome, Safari und Edge zumindest teilweise bereits unterstützt. Internet Explorer unterstützt diese Funktion zur Zeit jedoch nicht. Weitere Informationen zur Browser Kompatibilität sind unter [4] zu finden.
Dank der «Referrer Policy» lässt sich der Referer Header komplett deaktivieren oder auf den Domainnamen verkürzen. Dabei sind folgende Optionen möglich:
| Wert | Beschreibung |
|---|---|
| no-referrer | Der Header wird in keinem Fall mitgesendet |
| Origin | Nur der Domainname wird als Referer Header mit allen Requests mitgesendet. Dies findet auch statt, wenn von einer durch HTTPS verschlüsselte Verbindung auf eine HTTP Verbindung gewechselt wird. |
| Origin-when-cross-origin | Für Requests auf den gleichen Domainnamen wird der gesamte Referer Header gesendet. Für alle anderen Requests wird nur der Domainname gesendet. |
Die entsprechende Referrer Policy lässt sich im Server Header sowie im HTML Code der entsprechenden Seite definieren.
Referer Policy Definition durch HTML Code:
<meta name="referrer" content="no-referrer" />
Referer Policy Definition durch Server Header (Beispiel für apache2 Server):
set Content-Security-Policy "referrer no-referrer"
Fazit
HTTP Referer Header haben aus Marketing-Sicht durchaus ihre Berechtigung, sind aber aus Compliance-Sicht nicht unbedenklich. Wer die in diesem Artikel beschriebenen Massnahmen umsetzt kann die potentiellen Probleme jedoch umschiffen.
Autor: Fabian Gonzalez ist Penetration Tester bei der Oneconsult AG
Über Oneconsult
Die Oneconsult AG ist ein Schweizer Cybersecurity Consulting Unternehmen mit rund 25 Mitarbeitern, Büros in der Schweiz und Deutschland und einem Kundenstamm von 300+ Organisationen und 1200+ weltweit durchgeführten Projekten. Wir sind Ihr vertrauenswürdiger Partner für einen umfassenden Cybersecurity Ansatz gegen externe und interne Cyber-Bedrohungen wie APT, Hacker-Angriffe, Malware-Befall, digitalen Betrug und Datenverlust. Die Kerndienstleistungen von Oneconsult sind Penetration Tests, ISO 27001 Security Audits und IT-Forensik. Zum Schutz Ihrer Organisation und um spezifische Informationssicherheitsrisiken anzugehen, sind auch praxisorientiertes Security Consulting, Security Training und Virtual Security Officer Services Teil des Portfolios. Eigene IT Security Researcher, IT-Forensik-Experten (GCFE, GREM), ISO Security Auditoren (ISO 27001 Lead Auditor) und ein grosses Team an zertifizierten Penetration Testern (OPST, OSCP etc.) stehen Ihnen kompetent zur Verfügung.
[1] https://tools.ietf.org/html/rfc2616#section-14.36
[3] https://w3c.github.io/webappsec-referrer-policy/
[4] https://caniuse.com/#feat=referrer-policy
