Domain-übergreifende Hilfs-Cookies mit “window.name”
Die aktuelle Diskussion über Canvas-Fingerprints hat wieder gezeigt, dass sowohl Browser als auch HTML und JavaScript viele Einfallstore für Datensammler bieten. Viele Funktionen, die den Nutzern eigentlich den Umgang mit dem Web erleichtern sollen stellen sich früher oder später als Privacy-Lücke heraus (z.B. kann das Caching für einen ausgezeichneten Cookie-Ersatz verwendet werden).
Für Datensammler stellt sich jedoch immer auch das Problem der Domaingrenze. D.h. die Browser verhindern inzwischen den Zugriff auf Informationen oder Funktionen, die von einer anderen Domain im Browser angelegt wurden.
“window.name” funktioniert Domain-übergreifend
Allerdings gibt es mit dem Objekt window.name einen Store für beliebige Inhalte, die von einer Domain zur nächsten übermittelt werden können. Ein einfacher Test in der Browserconsole zeigt, wie es funktioniert:
> window.name
< ""
> window.name = "id"
< "id"
Ruft man nun in der aktuellen Seite einen Link auf, der auf eine andere Domain verweist und fragt wiederum window.name ab erhält man weiterhin “id”:
> window.name
< "id"
Die Ursprungsseite kann also Informationen an die Zielseite weiterleiten. Und dies obwohl bei in verschiedenen Domains liegen. Der Speicherplatz in der Variable kann dabei mehrere hundert KByte große sein.
Privacy-Lücke auch in Tor
Prinzipiell eignet sich das Verfahren damit für die Erkennung und Rekonstruktion von Nutzern insbesondere in anonymisierenden Umgebungen wie etwa Tor oder hinter privoxy. Tatsächlich überschreibt auch der Tor-Browser die Variable nicht, wenn eine neue Seite aufgerufen wird. Ein interessierter Angreifer kann Code auf bestimmte Seiten platzieren und den window.name setzen und auf anderen Seiten diesen wieder auslesen. Dabei muss die Variable nicht permanent gesetzt sein. Es genügt eine Funktion bei “unload” aufzurufen, die gewünschten Informationen in die Variable zu schreiben und beim Aufruf der neuen Seite wieder auszulesen und zu löschen.
Cross-Domain-Angriff möglich
Da in der Variable window.name nicht nur Strings sondern auch Code gespeichert werden kann, lässt sich so prinzipiell auch schadhafter Code auf fremden Seiten einschleusen. Das offensichtlichste Einfallstor sind weit verbreitete JavaScript-Frameworks, die auf das Objekt zugreifen. Wenn darin dann statt des erwarteten Strings Methoden stecken, kann das Framework dazu gebracht werden, diese fremden Funktionen auszuführen.
Ein kompromittiertes Banner zu einer Bankenseite kann dorthin Code deployen und dann unter anderer Domain und sogar https Zugangsdaten und PINs abgreifen oder gar gleich den Empfänger manipulieren.
Tatsächlich wird mit der Technik schon eine Weile rumgespielt. Auf github findet sich zum Beispiel ein jQuery-Plugin, das window.name explizit für Cross-Domain-Messageing verwendet.
Wie in so vielen Fällen schützt auch hier wieder nur JavaScript abzuschalten. Prinzipiell stellt sich aber die Frage, ob der window.name überhaupt noch zeitgemäß ist. Immerhin sind die Zeiten der Framesets und damit die Notwendigkeit der Frame-Namen glücklicherweise vorbei.
