XSS-Suche, Teil 3: Der Kontext bestimmt den Test
Nachdem Sie alle möglicherweise für XSS anfälligen Parameter der Webanwendung ermittelt und eine möglicherweise vorhandene Schutzfunktion erkannt haben, kann die Suche nach XSS-Schwachstellen los gehen.
Je nachdem, wo ein Parameter ausgegeben wird, müssen Sie andere Tests verwenden. Oder genauer: Sie müssen Ihren Test so an die Umgebung anpassen, dass er auch ausgeführt werden kann. Und nicht schon deshalb fehl schlägt, weil der Browser ihn gar nicht als ausführbar akzeptiert.
Beispiel 1: Ausgabe im normalen Text
Am einfachsten ist ein Angriff, wenn das eingegebene Testmuster, zum
Beispiel IIIXSSTestParameternameIII
, im normalen Text der
Seite erscheint, zum Beispiel die Eingabe für die Suchfunktion auf der
Ergebnisseite:
<p>
Die Suche nach 'IIIXSSTestParameternameIII' lieferte 0 Ergebnisse.
</p>
In diesem Fall kann der gewünschte Testcode, zum Beispiel
<script>alert('XSS')</script>
zum Öffnen einer Alertbox, direkt eingegeben werden. Das führt zur Ausgabe von
<p>
Die Suche nach '<script>alert('XSS')</script>' lieferte 0 Ergebnisse.
</p>
und beim Rendern der Seite wird der rot dargestellte Code ausgeführt und die Alertbox geöffnet.
In den allermeisten Fällen funktioniert so ein Angriff heutzutage nicht mehr, da der eingeschleuste Schadcode erkannt und entweder unbrauchbar gemacht oder komplett ausgefiltert wird. Aber so ein Schutz ist ja auch nur ein Programm, und das kann selbst wiederum Schwachstellen enthalten, durch die die Schutzfunktion ausgetrickst werden kann.
Nehmen wir mal an, dass der XSS-Schutz darin besteht, dass
script
-Tags ausgefiltert werden. Dann muss entweder ein
Angriff gewählt werden, der ohne script
-Tags auskommt,
oder die script
-Tags müssen an der Filterfunktion vorbei
geschleust werden (sofern das möglich ist).
Manchmal reagieren Filter nur auf "normal" geschriebene Tags wie
<script>
und <SCRIPT>
, während
zum Beispiel <sCrIpT>
nicht ausgefiltert wird. Den
Webbrowsern ist die Schreibweise egal, die führen auch den in
<sCrIpT>...</SCrIPt>
eingeschlossenen Code aus.
Vielleicht kann der Filter auch durch ein eingefügtes Leerzeichen
(<script >
) oder URL-codierte Zeichen
(%3cscript%3e
) ausgetrickst werden.
Auch die Schachtelung von Tags kann einfache Filter überlisten: Wird die
Eingabe nur einmal durchsucht und dabei jedes gefundene script
-Tag
gelöscht, würde eine Eingabe wie zum Beispiel
<scr<script>ipt>alert('XSS')</scr</script>ipt>
nach der Filterung, bei der die zur Tarnung eingefügten rot
hervorgehobenen vollständigen Tags <script>
und
</script>
gelöscht wurden, ausführbaren Code
ergeben.
Wie bereits erwähnt enthalten das XSS Filter Evasion Cheat Sheet von OWASP und das HTML5 Security Cheatsheet eine umfangreiche Sammlung von Möglichkeiten, Filter zu umgehen.
Beispiel 2: Ausgabe in input
-Tags
Manchmal erscheint das eingegebene Testmuster als Wert in einem input
-Tag:
<input type="text" name="foo" value="IIIXSSTestParameternameIII">
Einfach nur den XSS-Code, zum Beispiel das bereits oben verwendete
<script>alert('XSS')</script>
zum Öffnen einer Alertbox, einzuschleusen, funktioniert an dieser
Stelle nicht. Trotzdem ist ein XSS-Angriff möglich: Die Doppelten
Anführungszeichen um das Testmuster sowie das input
-Tag werden
geschlossen und der gewünschte XSS-Code angehängt:
"><script>alert('XSS')</script><!--
Die abschließende Zeichenkette <!--
leitet einen Kommentar
ein und verhindert Probleme durch die in der Ausgabe auf den
eingeschleusten Code folgenden Zeichen ">
. Mit dieser
Eingabe ergibt sich in der ausgegebenen Webseite
<input type="text" name="foo" value=""><script>alert('XSS')</script><!--">
und die Alertbox wird beim Rendern geöffnet.
Werden <
und >
oder auch komplette
script
-Tags ausgefiltert, ist das auch kein Problem. Dann kann
zum Beispiel einfach ein Event-Handler in das input
-Tag
eingefügt werden:
"onfocus="alert('XSS')
als eingeschleuster XSS-Code ergibt
<input type="text" name="foo" value=""onfocus="alert('XSS')">
Wenn der onfocus
-Event ausgelöst wird, wird der
eingeschleuste Code ausgeführt und in diesem Fall die Alertbox
geöffnet.
Beispiel 3: Ausgabe in img
-Tags
Das eingegebene Testmuster könnte auch im src
-Attribut eines
img
-Tags ausgegeben werden:
<img src="IIIXSSTestParameternameIII">
In einigen Browsern darf das Attribut eine URL mit dem
javascript:
-Protokoll enthalten, so das die Schwachstelle direkt ausgenutzt
werden kann:
javascript:alert('XSS');
ergibt
<img src="javascript:alert('XSS');">
wodurch der eingeschleuste Code beim Auswerten des img
-Tags ausgeführt
wird. Soll der Angriff in jedem Browser funktionieren, kann ein nicht
existierendes Bild angegeben und ein onerror
-Eventhandler mit dem
gewünschten Code eingefügt werden:
gibtesnicht.gif"onerror="alert('XSS')
ergibt
<img src="gibtesnicht.gif"onerror="alert('XSS')">
Da es das Bild nicht gibt, wird der onerror
-Eventhandler und
damit der eingeschleuste Code aktiv.
Beispiel 4: Ausgabe in JavaScript-Code
Es kann auch passieren, dass das Testmuster in einem JavaScript-Skript der Webseite ausgegeben wird:
<script>
var a=123;
var b='IIIXSSTestParameternameIII';
var c='abc'
...
</script>
Um darüber Code einzuschleusen, wird das einfache Anführungszeichen und danach mit einem Semikolon der Ausdruck beendet und dann der Schadcode eingefügt:
'; alert('XSS'); var nix='
Das angehängte var nix='
ist notwendig, da die Syntax des Skripts trotz der
Manipulation korrekt sein muss. Eingesetzt ergibt sich damit
<script>
var a=123;
var b=''; alert('XSS'); var nix='';
var c='abc'
...
</script>
Der Schadcode wird in diesem Fall zusammen mit dem Skript ausgeführt.
Zusammenfassung
Um mögliche XSS-Schwachstellen zu finden, müssen Sie zuerst alle Parameter ermitteln, die in den von der Webanwendung erstellten Seiten ausgegeben werden. Jedes Auftreten des Testmusters müssen Sie dann wie oben beschrieben daraufhin überprüfen, ob darüber Scriptcode eingeschleust werden kann. Dabei müssen Sie zwei Punkte beachten: Ist an der jeweiligen Stelle das Einschleusen von Code prinzipiell möglich (was fast immer der Fall sein wird) und wenn ja, können evtl. vorhandene Schutzfunktionen umgangen werden?
Jetzt wissen Sie zumindest in Grundzügen, wie Sie XSS-Schwachstellen in ihrer Webanwendung finden können. Viel wichtiger ist es aber, sie zu verhindern. Und darum geht es in der nächsten Folge.
Trackbacks