Bei der Suche nach XSS-Schwachstellen wurde bisher nach reflektierten (ab About Security #158) und persistenten (ab About Security #162) XSS gesucht. Was bisher fehlt, ist die Suche nach DOM-basierten XSS-Schwachstellen. Wie Sie die finden, erfahren Sie in dieser Folge.
Client-Problem
DOM-basiertes XSS ist ein reines Client-Problem. Wie bei der Beschreibung dieser Schwachstelle in About Security #129 und #130 bereits festgestellt wurde, ist der Schadcode nie Bestandteil der vom Server gelieferten HTML-Seite. Dem entsprechend können die Schwachstellen nicht wie reflektiertes und persistentes XSS durch die Eingabe eines Testmusters und anschließendem Durchsuchen der ausgegebenen Seiten nach diesem Testmuster gefunden werden.
1. Ansatz: Testcode eingeben
N E U ! Security aktuell
Täglich aktuelle Security-Infos!
Ein erster Ansatz zur Suche nach DOM-basierten XSS-Schwachstellen besteht
darin, jede Seite manuell mit dem Browser aufzurufen und für jeden
URL-Parameter einen Standardtest wie z.B. das altbekannte
<script>alert('XSS')</script>
oder
<script>alert(document.cookie)</script>
einzugeben. Beim Rendern der ausgegebenen Seite wird der enthaltene
Scriptcode unter Verwendung der manipulierten URL-Parameter
ausgeführt. Öffnet sich die Alertbox, ist über den
betroffenen Parameter DOM-basiertes oder reflektiertes XSS möglich.
Mit diesem Ansatz findet man aber nur die einfachsten Fälle von DOM-basierten XSS: Die, bei denen auf die Syntax des vorhandenen Skripts keine Rücksicht genommen werden muss. Wie in About Security #160 zu sehen war, erfordert ein XSS-Angriff oft ein Anpassung an den bereits vorhandenen Skriptcode. Der Code vor dem Parameter, der über den Parameter eingeschleuste Code und der ggf. auf den Parameter noch folgende Code müssen in ihrer Gesamtheit syntaktisch korrekt sein, damit der Code ausgeführt wird. Dabei gibt es viele Möglichkeiten, wie der eingeschleuste Code vorbereitet werden muss. Zum Beispiel müssen vorhandene einfache oder doppelte Anführungszeichen oder auch Skript-Tags eventuell korrekt geschlossen werden. Vielleicht muss auch ein neues Tag eingefügt oder Manipulationen des Parameters durch zuvor ausgeführten Code berücksichtigt werden usw.
Der oben angegebene Beispielcode führt beim Einfügen in die Seite vielleicht gerade nicht zu syntaktisch korrektem Code, sodass der eingefügte Code nicht ausgeführt und dadurch die Alertbox nicht geöffnet wird, obwohl prinzipiell XSS möglich wäre. Mit anderen Worten: Mit dem Ansatz findet man zwar DOM-basierte XSS-Schwachstellen, aber sehr wahrscheinlich nicht alle.
2. Ansatz: Client-Code untersuchen
Ein anderer Ansatz zur Suche nach DOM-basierten XSS-Schwachstellen besteht darin, den gesamten Client-seitigen JavaScript-Code auf DOM-Zugriffe zu untersuchen, die zu einer XSS-Schwachstelle führen können. Dazu können die zu Beginn der Schwachstellen-Suche gesammelten Informationen herangezogen werden: Alle Seiten werden nach JavaScript-Code durchsucht, der eines der folgenden Objekte enthält, über die Daten aus der URL abgefragt werden können:
- document.URL
- document.URLUnencoded
- document.location
- document.referrer
- window.location
Überall, wo diese Aufrufe auftauchen, muss die Verwendung der vom Benutzer manipulierbaren Parameter überprüft werden: Kann ein Parameter so manipuliert werden, dass darüber Code eingeschleust und ausgeführt werden kann? Besonders auf die folgenden Aufrufe muss dabei geachtet werden:
- document.body.innerHtml
- document.write()
- document.writeln()
- eval()
- window.execScript()
- window.setInterval()
- window.setTimeout()
Wie schon bei reflektierten und persistenten XSS können auch beim DOM-basierten XSS Filterfunktionen zum Zuge kommen, die Requests mit unerwünschten und/oder potenziell gefährlichen Inhalten abweisen oder filtern. Die verschiedenen Möglichkeiten, den eingeschleusten Code vor der Webanwendung auf dem Server zu verbergen, wurden bereits in About Security #130 vorgestellt. Außer den Schadcode komplett zu verbergen, besteht auch die Möglichkeit, die Filterfunktionen wie im Fall von reflektierten XSS auszutricksen (About Security #160 und #161).
Während sich einfache clientseitige Skripte noch manuell überprüfen lassen, ist bei komplexeren Skripten der Einsatz eines JavaScript-Debuggers, z.B. die Firefox-Erweiterung Firebug, äußerst hilfreich. Damit kann die Ausführung des Codes Schritt für Schritt nachvollzogen und auf mögliche Ansatzpunkte für XSS untersucht werden
Gegenmaßnahmen
DOM-basiertes XSS verhindert man am besten, indem auf dem Client auf die Verarbeitung vom Benutzer manipulierbarer Daten verzichtet wird. Ist das nicht möglich, müssen die Daten auf dem Client bei der Ein- und Ausgabe geprüft werden. Eingaben dürfen nur alphanumerische und Whitespace-Zeichen enthalten. Ausgaben müssen, bevor sie ins DOM geschrieben werden, als HTML kodiert werden. Dadurch wird eventuell eingeschleuster Schadcode als Text ausgegeben und nicht ausgeführt.
Damit ist die Suche nach XSS-Schwachstellen abgeschlossen. In der nächsten Folge geht es um die Suche nach einer weiteren weit verbreiteten Klasse von Schwachstellen: SQL-Injection-Schwachstellen.
Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!
Kommentare