News Drucken: About Security #130: DOM-basiertes XSS abwehren

Zur Tarnung des über DOM-basiertes XSS einzuschleusenden Schadcodes gibt es mehrere Möglichkeiten. Wie bereits in About Security #129 erwähnt, ist der Schadcode nie Bestandteil der vom Server gelieferten HTML-Seite. Nur die im Request mitgelieferten Query-Daten verraten ihn, aber auch das kann umgangen werden. Dazu wird der Schadcode als Fragmentbezeichner getarnt:

http://www.beispiel.example/index.html#name=<script>alert('XSS')</script>

Das #-Zeichen markiert den darauf folgenden Rest als Fragmentbezeichner. Der ist nicht Teil des URIs, sondern enthält Referenzierungsinformationen, die vom Browser nach dem Empfang der Ressource lokal ausgewertet werden. Die meisten Browser senden den Fragmentbezeichner nicht an den Server, der dadurch nur

http://www.beispiel.example/index.html

zu sehen bekommt. Dieser Trick funktioniert nicht immer. Z.B. ist eine solche Tarnung nicht möglich, wenn der Schadcode über den Benutzernamen oder das Passwort eines URLs nach dem Muster http://Benutzername:Passwort@www.beispiel.example eingeschleust wird. Der Schadcode wird dann als Bestandteil des Authorization-Headers an den Server gesendet, wo er erkannt werden kann. Er wird aber auch bei diesem Angriff nicht vom Server in die Antwort eingebettet, das erledigt später der Browser beim Parsen der empfangenen Seite.

N E U ! Security aktuell
Täglich aktuelle Security-Infos!

Wird der zum Einschleusen des Schadcodes verwendete Parameter vom Server geprüft, kann er durch das Einfügen eines zusätzlichen Parameters getarnt werden:

http://www.beispiel.example/index.html?noname=
<script>alert('XSS')</script>

Muss der Parameter name vorhanden sein, kann er einfach angehängt werden:

http://www.beispiel.example/index.html?noname=
<script>alert('XSS')</script>&name=Anton

Darf name nicht Bestandteil des zusätzlichen Parameters sein, kann er evtl. über einen Parameter mit anderen, zulässigen Namen getarnt werden:

http://www.beispiel.example/index.html?nix=name=
<script>alert('XSS')</script>&name=Anton

Der nicht verwendete Parameter nix kommt zuerst, als dessen Wert wird der für das Einschleusen verwendete Parameter samt Schadcode verwendet: name=<script>alert('XSS')</script>.

Schwachstellen finden

Wie zu sehen ist, kann der eingeschleuste Schadcode vor dem Server und allen serverseitigen Schutzeinrichtungen wie IDS/IPS oder Web Application Firewall verborgen werden. Dementsprechend funktionieren auch keine serverseitigen Filter. Auch die Erkennung durch die meisten Fuzzing nutzenden Schwachstellenscanner ist schwierig, da diese nur die Antworten des Servers auf die eingeschleusten Testdaten prüfen. Außer einer (ggf. automatisierten) Analyse des JavaScript-Codes können nur manuelle Tests über einen Browser und automatisierte Tests, die auch die Codeausführung auf dem Client prüfen, DOM-basierte XSS-Schwachstellen finden. Bei den letzten beiden müssen dabei alle DOM-Objekte mit passenden Werten besetzt sein.

Gegenmaßnahmen

Potenziell gefährlich sind alle Fälle, in denen die HTML-Seite selbst oder das DOM manipuliert werden. Dabei ist darauf zu achten, woher die verwendeten Daten kommen und ob ein Angreifer sie manipulieren kann. Sind Änderungen des Clients am DOM mit vom Client und damit einem möglichen Angreifer manipulierbaren Daten notwendig, müssen diese auf dem Client geprüft werden. Das betrifft z.B. die schon in About Security #129 erwähnten document-Objekte, aber auch z.B. window.location und deren Eigenschaften.

Die einfachste Gegenmaßnahme besteht darin, auf dem Client weder Änderungen am DOM noch sensitive Aktionen mit vom Client gelieferten Daten zuzulassen. Wann immer möglich, sollten dafür serverseitige Skripts verwendet werden.

Nur weil über DOM-basiertes XSS eingeschleuster Schadcode getarnt werden kann, darf auf serverseitige Prüfungen durch IDS/IPS oder Web Application Firewall nicht verzichtet werden. Strenge Regeln, die festlegen, welche Parameter vorhanden sein müssen und/oder dürfen und wie deren Werte aufgebaut sind, erschweren ein Ausnutzen DOM-basierter XSS-Schwachstellen.

Die Folgen – was kann XSS?

Ab jetzt geht es wieder allgemein um XSS-Angriffe. Wie der Schadcode in den Browser des Opfers gelangt, ist dabei unerheblich.

XSS ist eine seit langem bekannte Schwachstelle. Inzwischen haben sich nicht nur die Webanwendungen, sondern natürlich auch die Schädlinge dazu weiterentwickelt. Durch die Entwicklung vom Web zum Web 2.0 mit seinen AJAX-Bibliotheken, neuen Formaten wie JSON und neuen Verbreitungswegen wie RSS und REST/SOAP sind auch die Möglichkeiten der Angreifer gewachsen.

Die möglichen Folgen eines XSS-Angriffs reichen vom Einschleusen gefälschter Inhalte über das Ausspähen von Passwörtern und Authentifizierungs-Cookies bis zur Ausnutzung von Schwachstellen im Browser, um eigenen Code auszuführen und dadurch das angegriffene System zu kompromittieren.

Einige Beispiele:

Ein Angreifer, der JavaScript ausführen kann, hat die Kontrolle über den Browser:
- Ausspähen von Cookies (siehe auch About Security #14)
- Ausspähen von Tastatureingaben oder Mausevents
- Auslesen von Passwörtern aus z.B. dem Password-Safe von Firefox oder dem Schlüsselring von Mac OS X
- Ausspähen der Browser-History
- Einschleusen falscher Informationen
Wer die Kontrolle über den Browser hat, befindet sich im lokalen Netz – und damit hinter der Firewall:
- Portscan über JavaScript
- Ausnutzung von Default-Passwörtern in Netzwerkhardware
Wer die Kontrolle über den Browser hat, ist nur einen Schritt von der Kontrolle über das System entfernt – er muss "nur" eine Schwachstelle finden und ausnutzen.

Das Ausspähen von Cookies und Tastatureingaben sowie das Auslesen von Passwörtern werden in der nächsten Folge als erste Angriffe über XSS vorgestellt.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen – Cross-Site Scripting"