© istockphoto.com/topform84, © istockphoto.com/ChrisGorgio
Je mächtiger der Webbrowser und -client, desto interessanter für Angriffe

Webbrowser und Webclient als Angriffsziel


Die Browser enthalten immer mehr Funktionen, die Webclients werden immer mächtiger. Das erste freut die Webentwickler, das zweite die Nutzer. Und die Angreifer freuen sich über beides, denn je mehr Funktionen der Browser bereitstellt, desto mehr können sie für ihre Zwecke missbrauchen. Außerdem gilt: Je mehr Funktionen in den schlechter zu schützenden Webclient ausgelagert werden, desto leichter lassen sie sich angreifen.

Der Webclient als Angriffsziel ist eigentlich immer aktuell. Im PHP Magazin 4.2015 ging es um die nach wie vor aktuelle Cross-Site Request Forgery [1], im PHP Magazin 6.2014 um Angriffe über die Grafikfunktionen von HTML5 [2], im PHP Magazin 4.2014 um das ebenfalls sehr langlebige Clickjacking [3] und im PHP Magazin 2.2014 um Angriffe auf den Webclient allgemein [4] – von den älteren Artikeln ganz zu schweigen. Da wird es dringend Zeit für ein Update. Weitestgehend beschränke ich mich dabei auf einige der 2015 auf den Sicherheitskonferenzen vorgestellten bzw. beschriebenen neuen Angriffe auf und über Webbrowser und -client.

Zum Glück gibt es die Angriffe in den meisten Fällen bisher nur in der Theorie, sodass Sie eine Chance haben, die von den Sicherheitsforschern erkannten Angriffsmöglichkeiten durch entsprechende Gegenmaßnahmen abzuwehren, bevor es zu tatsächlichen Angriffen kommt. In der Praxis hat das bisher aber leider nicht immer funktioniert: Sowohl CSRF als auch Clickjack­ing sind seit Langem ebenso bekannt wie die möglichen Schutzmaßnahmen, und trotzdem kommt es „in the wild“ immer wieder zu solchen Angriffen. Also: Schützen Sie Ihre Webanwendungen vor den neuen Angriffsmöglichkeiten, bevor die Cyberkriminellen sie ausprobieren. Oft ist das ganz einfach, aber darauf komme ich später noch zurück.

Der Einfachheit halber geht es im Folgenden chronologisch weiter, und wie so oft konzentriere ich mich auf die Black-Hat-Konferenzen, da die einfach die besten Archive haben und man nicht mühsam Präsentationen, Material und Videos zusammensuchen muss.

Schutz vor DOM-basiertem XSS, aber richtig!

So ähnlich hieß ein von Martin Johns, Sebastian Lekies und Ben Stock auf der Black Hat Asia im März 2015 gehaltener Vortrag: „Client-Side Protection Against DOM-Based XSS Done Right (TM)“ [5]. DOM-basiertes XSS ist schon ziemlich alt; erstmals beschrieben wurde es 2005 von Amit Klein [6]. Nach inzwischen über zehn Jahren sollte man doch davon ausgehen, dass entsprechende Schwachstellen nicht mehr vorkommen. Leider ist das natürlich nicht der Fall, ganz im Gegenteil – je mehr Funktionen in den Webclient ausgelagert werden, desto mehr Möglichkeiten gibt es, dabei DOM-basierte XSS-Schwachstellen zu implementieren. Bei einem Test der Alexa-Top-10K-Websites fanden die drei Forscher 1 602 eindeutige Schwachstellen auf 958 Domains. Dabei kam auch heraus, dass Google Chromes Schutz vor XSS-Schwachstellen in Form des „XSS Auditors“ nicht alle Angriffe abfängt. Ursache sind die Erkennungsroutinen des Auditors, der primär ein HTML-Parser ist, obwohl beim XSS im Allgemeinen JavaScript-Code eingeschleust wird.

Der Auditor spricht nur auf bestimmte Zeichen im Request (<, >, " und ') an, prüft nur auf bekannte Angriffsmuster, stoppt die Suche beim Auftreten bestimmter Zeichen und so weiter. Angriffe, die ohne die kritischen Zeichen auskommen, haben eine gute Chance, unentdeckt zu bleiben, Gleiches gilt für Angriffe, die hinter den „Stopzeichen“ quasi verborgen werden. Dazu kommen weitere Angriffsmöglichkeiten, die vom Auditor übersehen werden. Bei einem erneuten Test der 958 Domains der Alexa Top 10K mit XSS-Schwachstellen stellte sich heraus, dass bei 776 davon der Schutz durch den XSS Auditor umgangen werden kann. Dabei muss man dem XSS Auditor zugutehalten, dass er nicht zur Abwehr von clientseitigem XSS entworfen wurde. Das lässt sich aber ändern, indem zunächst auf „Taint Tracking“ statt auf die Approximation des Datenflusses gesetzt wird – und zwar im JavaScript-, nicht im HTML-Parser. Wenn man dann noch berücksichtigt, dass Daten in JavaScript Literale (numerisch, String, Boolean) sind, führt das im Endeffekt dazu, dass „Tainted Data“ – also alle vom Benutzer manipulierbaren Daten – in der JavaScript Engine nur in Literale umgewandelt werden dürfen. Außerdem darf kein Element, das eine externe Ressource referenziert, eine „tainted“ Origin haben – mit einer einzigen Ausnahme: die Origin der einbindenden Seite.

Diese vorgeschlagenen Verbesserungen für den XSS Auditor von Google Chrome gelten entsprechend natürlich für alle XSS-Filter, die nach ähnlichen Grundsätzen arbeiten.

Ein kurzer Abstecher ...

... ins Jahr 2014: Die drei Forscher haben auch auf der Black Hat Europe im Oktober 2014 einen Vortrag mit dem Titel „Session Identifier are for Now, Passwords are Forever – XSS-Based Abuse of Browser Password Managers“ [7] gehalten. Der Titel sagt wohl genug: Vorgestellt wurden Möglichkeiten, über XSS die Passwortmanager der Browser zur Preisgabe der gespeicherten Zugangsdaten für eine Website mit einer XSS-Schwachstelle zu bewegen. Das Fazit des Vortrags fällt wie erwartet aus: Die Passwortmanager lassen sich alle mehr oder weniger einfach austricksen.

Die Forscher haben natürlich auch hier eine Lösung vorgeschlagen [8]. Eigentlich sollen die Passwortmanager ja die Benutzer bei der Authentifizierung unterstützen, worunter man normalerweise das Senden der Zugangsdaten an den Server versteht. Implementiert ist das aber nur indirekt, indem die Zugangsdaten in das Formular der Website eingetragen werden, das der Benutzer dann selbst abschickt. Deshalb können sie im Formular auch ausgespäht werden. Die vorgeschlagene Lösung besteht daher darin, dass die Passwortmanager die Formulare nicht mit Benutzernamen und Passwort ausfüllen, sondern nur mit dem Benutzernamen und einem Platzhalter für das Passwort. Der Platzhalter wird erst im Request mit dem abgesendeten Formular durch das Passwort ersetzt. Um Manipulationen am Formularziel zu verhindern, muss das in diesem Fall natürlich besonders sorgfältig geprüft werden; außerdem sollten die Passwörter nur in POST-Requests eingefügt werden.

Für Sie als Webentwickler ist der Schutz Ihrer Nutzer vor solchen Spähangriffen ganz einfach. Ihre Webanwendung darf keine XSS-Schwachstelle enthalten, schon ist das Ausspähen nicht mehr möglich. Diese Lösung wird Ihnen im Laufe des Artikels noch des Öfteren begegnen.

Der Browser weiß, wo Sie sind – und er verrät es

Kommen wir zum nächsten Vortrag aus dem Jahr 2015, wieder von der Black Hat Asia. Gehalten wurde er von Yaoqi Jia zum Thema „Geo-Inference Attacks via the Browser Cache“ [9]. Worum es ging, wird deutlich, wenn man den Anfang des Titels – „I Know Where You’ve Been“ – dazu nimmt: Der Browsercache verrät einem Angreifer (oder auch einem neugierigen Webseitenbetreiber), wo sich der Besucher einer Website befindet und auf welchen Websites er zuvor war, aber das interessiert in diesem Fall nicht. Yaoqi Jia präsentiert die Forschungsergebnisse einer Gruppe von Forschern der National University of Singapore [10].

Meist verrät man seinen Standort ja schon durch die IP-Adresse, auch wenn ich darüber mitunter an Orten vermutet werde, bei denen ich nicht einmal weiß, wo die denn liegen sollen – hier in der Gegend jedenfalls nicht. Dazu kommen weitere Möglichkeiten, den Standort eines Rechners zu bestimmen, zum Beispiel über den Zugriff auf den GPS-Sensor oder das einfache Nachfragen beim Benutzer. Mitunter möchte man seinen Standort aber gezielt verbergen, zum Beispiel wenn man eine Website über das Tornetzwerk oder einen VPN-Dienst in einem anderen Land aufruft. Dann funktioniert schon mal die Standortbestimmung anhand der IP-Adresse nicht mehr, und den Zugriff auf den GPS-Sensor wird man natürlich untersagen. Auch auf die Frage nach dem Standort wird man dann sicher nicht mit der Wahrheit antworten. Das schützt aber nicht zwingend vor der Erkennung des korrekten Standorts, denn der lässt sich mitunter aus den Daten im Browsercache ermitteln.

Im Cache werden statische Ressourcen der besuchten Websites gespeichert. Das kann ein Angreifer nutzen, um zu prüfen, ob eine bestimmte Website zuvor bereits besucht wurde. Er muss dazu einfach nur eine bekannte Ressource einer Website laden, zum Beispiel ein Bild, und messen, wie lange dieses Laden dauert. Befindet sich die Ressource im Cache, weil der Benutzer die Web­site zuvor schon besucht hat, wird sie sehr viel schneller geladen, als wenn der Browser sie erst vom Server anfordern muss. Der Standort des Rechners lässt sich ermitteln, weil im Allgemeinen die am nächsten gelegene Version einer Website besucht wird, beziehungsweise die meisten Websites ihre Besucher auf diese Version weiterleiten. So hat zum Beispiel Google 191 regionale Sites, die jeweils einem Land oder einer Region zugeordnet sind. Wird dann zum Beispiel das Google-Logo von http://www.google.com.sg/ so schnell geladen, dass es aus dem Cache und nicht vom Server kommt, bedeutet das erst einmal, dass der Benutzer die Google-Website für Singapur bereits besucht hat. Er ist oder war also wahrscheinlich zumindest in der Nähe von Singapur.

Diese Vermutung wird umso wahrscheinlicher, je mehr weitere passende lokale Websites bereits besucht wurden. Zum Beispiel betreibt Craigslist 712 stadtspezifische Sites, und zumindest für den An- und Verkaufsbereich wird der Benutzer im Allgemeinen die lokale Website seiner Stadt wählen bzw. die der Stadt, die ihm am nächsten liegt. Noch genauere Informationen liefern die Daten, die Google Maps im Cache speichert – zumindest, wenn der Benutzer zumindest ab und zu eine Route von oder zu seinem üblichen Standort berechnen lässt.

Yaoqi Jia hat überprüft, ob sich der Standort eines Benutzers wirklich auf diesem Weg bestimmen lässt und wie genau die Ergebnisse sind. Immerhin hängen die davon ab, wie viele Websites für die Ortsbestimmung genutzt werden können ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang