Security-Funktion HSTS als Supercookie

Eine eigentlich sinnvolle Sicherheitsfunktion lässt sich auch für effektives Tracking missbrauchen – über die Grenzen des Inkognito-Modus hinaus. Das Problem ist seit Jahren bekannt, Abhilfe ist derzeit nicht in Sicht. Ob man betroffen ist, zeigt eine Testseite.

Ein Forscher hat eindrucksvoll demonstriert, wie gut sich die Sicherheitsfunktion HTTP Strict Transport Security (HSTS) für Web-Tracking eignet. Websites können über den HTTP-Header HSTS festlegen, dass sich der Browser des Besuchers für einen bestimmten Zeitraum ausschließlich über HTTPS mit dem Server verbindet. Das erschwert Man-in-the-Middle-Angriffe: Ruft der Nutzer etwa die Adresse http://paypal.com auf, steuert der Browser direkt https://paypal.com an, ohne dass ein Angreifer die sonst stattfindende Umleitung auf die verschlüsselte Ausgabe mit Tools wie sslstrip verhindern kann.

Allerdings kann ein Server-Betreiber damit auch hartnäckige Supercookies bauen, die der Nutzer unter Umständen nie wieder los wird. Anders als gewöhnliche Cookies überwindet das HSTS-Tracking sogar den Inkognito-Modus der Browser.

Wie es geht

Der Browser lädt beim ersten Besuch der Demoseite des Forschers Sam Greenhalgh im Hintergrund eine ganze Batterie an URLs von etlichen Subdomains wie etwa 1.example.com, 2.example.com, 3.example.com etc. nach. Der Server antwortet unter anderem stets mit dem HSTS-Header:

Strict-Transport-Security: max-age=31536000

Nachdem die HSTS-Werte gesetzt wurden, ruft der Browser einige URLs der Tracking-Seite über HTTPS auf, die anderen über HTTP. Diese Konstellation ist bei jedem Besucher einzigartig. Der Wert max-age, über den der Server festlegt, wie lange sich der Browser den HTTPS-Zwang merken soll, variiert allerdings. Entweder ist der Wert 31536000, was der Maximaldauer von einem Jahr entspricht, oder aber 0 – in letzterem Fall vergisst der Browser die Anweisung sofort wieder. Welche Werte der Browser bekommt, ist bei jedem Besucher anders – so ergibt sich eine individuelle Konstellation, aus welcher der Server eine einzigartige ID wie etwa g9xgoq generiert.

Beim nächsten Besuch ruft der Browser gemäß der zuvor gesetzten HSTS-Werte einige der URLs über HTTPS auf (max-age=31536000), die anderen über HTTP (max-age=0). Wird eine URL verschlüsselt abgerufen, liefert der Server ein true zurück, ansonsten ein false. Diese Werte wertet die Demoseite über JavaScript aus und kann so die individuelle ID g9xgoq rekonstruieren.

Inkognito-Modus ausgehebelt

Die Testseite liest im Inkognito-Modus (rechts) die Tracking-ID der Hauptsitzung (links) aus. Normalerweise ignoriert der Browser die bereits gespeicherten Cookies, wenn man ein privates Browserfenster öffnet (auch als Inkognito-Modus bekannt). Schließt man das Fenster, werden die während der privaten Session gesammelten Cookies verworfen. Das HSTS-Tracking überwindet diese Barriere: Im privaten Modus kann ein Server die während einer normalen Browsersitzung gesetzte Tracking-ID auslesen. Um die ID zu löschen, genügt es zumeist, den Verlauf des Browsers zurückzusetzen.

Unter iOS scheint es derzeit allerdings keinen Weg zu geben, eine über HSTS gesetzte Tracking-ID wieder los zu werden. Die Situation ist dort sogar noch brisanter: Wer seine Apple-Geräte über die iCloud synchronisiert, gleicht damit auch die Tracking-ID geräteübergreifend ab. Nutzer des Internet Explorer sind dieses Mal fein raus, da der Microsoft-Browser diese Sicherheitsfunktion erst ab der kommenden Version 12 unterstützen.

Problem erkannt, aber nicht gebannt

Ganz neu ist das Tracking über HSTS nicht, es wurde sogar bereits in der Spezifikation erwähnt:

14.9. Creative Manipulation of HSTS Policy Store
Since an HSTS Host may select its own host name and subdomains thereof, and this information is cached in the HSTS Policy store of conforming UAs, it is possible for those who control one or more HSTS Hosts to encode information into domain names they control and cause such UAs to cache this information as a matter of course in the process of noting the HSTS Host. This information can be retrieved by other hosts through cleverly constructed and loaded web resources, causing the UA to send queries to (variations of) the encoded domain names. Such queries can reveal whether the UA had previously visited the original HSTS Host (and subdomains). Such a technique could potentially be abused as yet another form of "web tracking" [WebTracking].

Wie das Problem zu lösen ist, geht aus der Spezifikation allerdings nicht hervor. Für das Chromium-Projekt, von dem Google Chrome abstammt, wurde vor drei Jahren ein Patch eingereicht, der dafür sorgen soll, dass eine Inkognito-Session nicht den HSTS-Status der normalen Sitzung erbt. Dieser hat das Datenleck jedoch offensichtlich nicht ausreichend abgedichtet. Der Bugtracker des Tor-Projekts führt das das HSTS-Tracking bereits seit zwei Jahren. Ob das Verfahren bereits von den Tracking-Firmen einsetzt wird, ist derzeit nicht bekannt. (rei)