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:

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.

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 aktuellen 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.

Carsten Eilers