Dipl.-Inform. Carsten Eilers

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.

Carsten Eilers