entwickler.com

In dieser Folge geht es um kompliziertere XSS-Schwachstellen im Vergleich zu den einfachen Fällen, die in About Security #158 vorgestellt wurden. In About Security #159 erfuhren Sie, wie man genauer zu untersuchende Parameter in einer Webanwendung findet. Ab dieser Folge dreht sich alles um die Frage, ob die gefundenen Parameter XSS-Angriffe erlauben oder nicht.

Beispiel 1: Normaler Text

Das eingegebene Testmuster, z.B. ##XSS-Test##, erscheint im normalen Text der Seite:

<p>
Die Suche nach '##XSS-Test##' lieferte 0 Ergebnisse.
</p>

In diesem Fall kann der gewünschte Schadcode, z.B.

<script>alert('XSS')</script>

direkt eingegeben werden:

<p>
Die Suche nach '<script>alert('XSS')</script>' lieferte 0 Ergebnisse.
</p>

Beim Rendern der Seite wird die Alertbox geöffnet.

Der Angriff wird schwieriger, wenn z.B. 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 vorbeigeschleust werden.

Oft reagieren Filter nur auf "normale" Tags wie <script> und <SCRIPT>, während z.B. <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 jeder gefundene script-Tag gelöscht, würde eine Eingabe wie z.B.

<scr<script>ipt>alert('XSS')</scr</script>ipt>

nach der Filterung, bei der die zur Tarnung eingefügten vollständigen Tags <script> und </script> gelöscht wurden, ausführbaren Code ergeben.

Das XSS Cheat Sheet enthält eine ganze Reihe möglicher Alternativen, um Filter zu umgehen.

Beispiel 2: input-Tags

Das eingegebene Testmuster erscheint in einem input-Tag:

<input type="text" name="foo" value="##XSS-Test##">

Einfach nur den XSS-Code, z.B.

<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 folgenden Zeichen ">:

<input type="text" name="foo" value=""><script>alert('XSS')</script><!--">

Werden < und > oder auch komplette script-Tags ausgefiltert, ist das auch kein Problem. Dann kann 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.

Beispiel 3: img-Tags

Das eingegebene Testmuster erscheint im src-Attribut eines img-Tags:

<img src="##XSS-Test##">

In einigen Browsern darf das Attribut einen URL mit dem javascript:-Protokoll enthalten, sodass 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')">

Beispiel 4: JavaScript

Das Testmuster erscheint in einem JavaScript-Skript der Webseite:

<script>
 var a=123;
 var b='##XSS-Test##';
 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 zusammen mit dem Skript ausgeführt.

Zusammenfassung

Um mögliche XSS-Schwachstellen zu finden, müssen zuerst die Parameter ermittelt werden, die in der von der Webanwendung erstellten Seite ausgegeben werden. Dazu wird für jeden Parameter ein Testmuster eingegeben und dies in der erzeugten Seite gesucht. Jedes Auftreten des Testmusters in der Webseite muss dann daraufhin überprüft werden, ob darüber Scriptcode eingeschleust werden kann. Dabei sind zwei Punkte zu beachten: Ist an der jeweiligen Stelle das Einschleusen von Code prinzipiell möglich und wenn ja, können eventuell vorhandene Schutzfunktionen umgangen werden?

Während bei der Suche nach XSS-Schwachstellen alle Parameter geprüft werden müssen, reichen zur Verhinderung von XSS-Angriffen wenige Schritte aus. Wie Sie XSS-Angriffe verhindern, erfahren Sie in der nächsten Folge.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Schwachstellensuche – III. Angriffe über vom Benutzer gelieferte Daten: XSS"

• About Security #158: Schwachstellensuche: Einfaches XSS
• About Security #159: Schwachstellensuche: XSS trotz Filter
• About Security #160: Schwachstellensuche: XSS finden
• About Security #161: Schwachstellensuche: XSS verhindern
• About Security #162: Schwachstellensuche: Persistentes XSS (1)
• About Security #163: Schwachstellensuche: Persistentes XSS (2)
• About Security #164: Schwachstellensuche: Persistentes XSS (3)
• About Security #165: Schwachstellensuche: DOM-basiertes XSS