Donnerstag, 30. August 2012


Topthema

Donnerstag, 24. Juli 2008 | Topthema

About Security #165: Schwachstellensuche: DOM-basiertes XSS

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

Bei der Suche nach XSS-Schwachstellen wurde bisher nach reflektierten (ab About Security #158) und persistenten (ab About Security #162) XSS gesucht. Was noch 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. Dementsprechend 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 Schwachstellensuche gesammelten Informationen herangezogen werden: Alle Seiten werden nach JavaScript-Code durchsucht, der eines der folgenden Objekte enth�lt, �ber die Daten aus dem 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 Zug 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).

About Security: Die komplette Serie

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!

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