Freitag, 31. August 2012


Topthema

Donnerstag, 10. Juli 2008 | Topthema

About Security #163: Schwachstellensuche: Persistentes XSS (2)

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

Die ersten Schritte bei der Suche nach persistenten Cross-Site-Scripting-Schwachstellen wurden in About Security #162 beschrieben: F�r jeden Parameter wird ein Testmuster eingegeben, danach in der gesamten Webanwendung nach dessen Auftreten gesucht. Dabei muss insbesondere auch der Administrationsbereich untersucht werden, sofern einer vorhanden ist. Das Gleiche gilt f�r alle Bereiche, die erst nach einer besonderen Authentifizierung zug�nglich sind. Immer, wenn ein normaler Benutzer XSS-Code von Benutzern mit h�heren Rechten ausf�hren lassen kann, besteht eine besonders gro�e Gefahr.

Ein Testmuster, oder besser viele?

Wie schon erw�hnt, m�ssen die eingegebenen Testmuster auf jeder Seite der Webanwendung gesucht werden. Daher ist es wenig hilfreich, einfach ein Testmuster in jeden erreichbaren Parameter einzugeben und dann hinterher danach zu suchen. Dadurch erh�lt man zwar sehr viele Fundstellen f�r dieses Testmuster, wei� aber nicht, �ber welchen Parameter es an die jeweilige Fundstelle gelangt ist. F�r dieses Problem bieten sich zwei L�sungswege an:

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

  1. Die Parameter werden einzeln, einer nach dem anderen, getestet.
    Das bedeutet: F�r den ersten gefundenen Parameter wird das Testmuster eingegeben, danach die Webanwendung nach dem Testmuster durchsucht und im Erfolgsfall gepr�ft, ob XSS m�glich ist.
    Danach muss das Testmuster gel�scht werden, um daraufhin das gleiche mit dem n�chsten Parameter zu wiederholen usw.
  2. Alle Parameter werden auf einmal getestet.
    Soll das Testmuster f�r alle Parameter auf einmal eingegeben werden, muss es um Informationen dar�ber, wo es eingegeben wurde, erweitert werden. Dazu kann z.B. der Name des Parameters an das Testmuster angeh�ngt werden. Kann der Parameter auf mehreren Seiten eingegeben werden, muss auch die jeweilige Seite angegeben werden.
    Nachdem die Testmuster f�r alle Parameter eingegeben wurden, wird die gesamte Webanwendung nach dem einheitlichen Teil des Testmusters durchsucht und danach die dadurch als m�gliche Einfallstore identifizierten Parameter �berpr�ft.

Im Allgemeinen ist der zweite Ansatz deutlich effektiver, da man dabei im Wesentlichen mit zwei Durchl�ufen der Webanwendung auskommt: Beim ersten Durchlauf werden alle Parameter mit dem Testmuster gef�ttert, beim zweiten das Testmuster in allen ausgegebenen Seiten gesucht.

Mehrere Schritte, eine Schwachstelle

Nicht immer reicht es aus, Testmuster einfach auf jeder Seite der Webanwendung in jeden Parameter einzugeben. Oft sind mehrere Schritte, verteilt auf mehrere Seiten, notwendig, bis eine Eingabe tats�chlich von der Webanwendung gespeichert wird. Typische Beispiele daf�r sind Registrierungsfunktionen f�r neue Benutzer, Eink�ufe �ber einen Warenkorb oder auch das Durchf�hren von �berweisungen. Um wirklich jede m�gliche Schwachstelle zu finden, m�ssen in solche F�llen die kompletten Prozeduren bis zu ihrem Ende durchgegangen und die entsprechenden Felder ausgef�llt und Aktionen ausgel�st werden.

About Security: Die komplette Serie

Als Beispiel soll wieder einmal der in About Security #153 beschriebene Webshop dienen. Beim Test des Webshops reicht es nicht aus, einfach in jedes vorhandene Eingabefeld ein Testmuster einzugeben, die Bestellung muss auch korrekt abgeschlossen werden. Meist gibt es je nach aktuellem Zustand auf der Folgeseite unterschiedliche Eingabefelder: Ein bekannter und identifizierter Benutzer muss seine Zahlungsinformationen nicht erneut eingeben, kann aber vielleicht eine alternative Lieferadresse angeben. Vielleicht gibt es auch auf der letzten Seite die M�glichkeit, eine Nachricht an den Shopbetreiber zu schicken. Je nachdem, ob die Bestellung abgebrochen oder erfolgreich abgeschlossen wurde, k�nnten dabei andere Eingabefelder erscheinen oder die Eingaben anders verarbeitet werden. All diese M�glichkeiten m�ssen bei der Suche nach XSS-Schwachstellen ber�cksichtigt werden.

Upload, Download, XSS-load?

Erlaubt die Webanwendung den Up- und/oder Download von Dateien, m�ssen diese ebenfalls als m�gliche Einfallstore f�r persistentes Cross-Site Scripting betrachtet und entsprechend gepr�ft werden. Insbesondere HTML- und Textdateien laden nat�rlich dazu ein, Scriptcode einzuf�gen. Aber auch andere Dateitypen k�nnen eine Gefahr sein. D�rfen Bilder, z.B. zur Darstellung von Avataren, hochgeladen werden, kann in einer solchen Datei enthaltener Scriptcode Benutzer des Internet Explorers und evtl. auch anderer Browser angreifen. Manche Browser, insbesondere der IE, f�hren in angeblichen Bildern gefundenen Scriptcode aus, statt ein defektes Bild zu melden. Auch andere Dateitypen k�nnen Scriptcode enthalten. Ein gutes Beispiel daf�r sind Flash-Dateien, wie es vom Orkut-XSS-Wurm demonstriert wurde (siehe About Security #141). Die Up- und Download-Funktionen m�ssen daher f�r jeden zul�ssigen Dateityp �berpr�ft werden.

Die restlichen Schritte zum Finden persistenter XSS-Schwachstellen werden in der n�chsten Folge beschrieben.

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