Freitag, 31. August 2012


Topthema

Donnerstag, 19. Juni 2008 | Topthema

About Security #160: Schwachstellensuche: XSS finden

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/043800)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

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.

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

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.

About Security: Die komplette Serie
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.

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 "Schwachstellensuche � III. Angriffe �ber vom Benutzer gelieferte Daten: XSS"

Kommentare

Folgende Links könnten Sie auch interessieren