Donnerstag, 30. August 2012


Topthema

Donnerstag, 3. Juli 2008 | Topthema

About Security #162: Schwachstellensuche: Persistentes XSS (1)

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

Bisher ging es bei der Suche nach Cross-Site-Scripting-Schwachstellen im Wesentlichen um reflektiertes Cross-Site Scripting. Diese Schwachstellen kann man recht einfach erkennen, da ein eingegebenes Testmuster sofort in der ausgegebenen Seite erscheint. Schwierig wird das bei persistenten Schwachstellen: Dort wird der eingeschleuste Schadcode bzw. das eingeschleuste Testmuster auf dem Server gespeichert und erst sp�ter, eventuell in einem ganz anderen Zusammenhang, an die Benutzer ausgegeben. Ab dieser Folge erfahren Sie, wie Sie solche Schwachstellen in Ihrer Webanwendung finden.

Drei Beispiele

Die folgenden drei F�lle sind typische Beispiele f�r persistentes XSS. Der Einfachheit halber wird im Folgenden nur noch das Testmuster erw�hnt, Entsprechendes gilt dann immer auch f�r den vom Angreifer eingeschleusten Schadcode.

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

  1. Kommentare in einem Blog
    Das in einem Kommentar eingegebene Testmuster wird von der Webanwendung z.B. in einer Datenbank gespeichert und danach zusammen mit dem zugeh�rigen Blogeintrag ausgegeben. Erfolg die Eingabe auf der Seite des zu kommentierenden Eintrags und wird diese Seite nach Absenden des Kommentars aktualisiert, l�sst sich eine XSS-Schwachstelle ebenso wie beim reflektierten XSS sofort erkennen: Das Testmuster erscheint sofort in der Ausgabe.
    Werden die Eintr�ge moderiert, ist diese Erkennung nicht m�glich. Erst wenn der Moderator den Beitrag freigeschaltet hat, erscheint das Testmuster in der Ausgabe. Entsprechend ist die Schwachstelle nicht sofort zu erkennen, daf�r gibt es mit dem Moderator ein zus�tzliches potenzielles Opfer, das noch dazu f�r die Webanwendung h�here Rechte als ein normaler Benutzer besitzt.
  2. Informationen in einem Profil, z.B. in einem Forum
    Beim Erstellen eines Profils w�hrend der Registrierung f�r ein Forum werden die eingegebenen Daten samt enthaltenen Testmuster meist nur auf dem Server gespeichert und nicht sofort wieder ausgegeben. Erst wenn die betroffene Profilseite explizit aufgerufen wird, erscheint das Testmuster in der Ausgabe. Muss das Benutzerkonto erst durch den Betreiber freigeschaltet werden, ist gar keine sofortige Kontrolle m�glich. Wie im vorherigen Beispiel ist in diesem Fall der f�r die Freigabe zust�ndige Administrator ein weiteres potenzielles Opfer mit h�heren Benutzerrechten.
  3. Eintr�ge in Logfiles
    Ob XSS �ber Logfile-Eintr�ge m�glich ist, kann von einem normalen Benutzer und damit einem potenziellen Angreifer �berhaupt nicht direkt gepr�ft werden. Ob ein Testmuster �ber ein Logfile in den Webbrowser eines Administrators eingeschleust werden kann, kann nur der jeweilige Administrator pr�fen. Der Angreifer hat nur die M�glichkeit, seinen Angriffscode einzuschleusen und auf das Beste zu hoffen. Als Test kann z.B. Code zum Laden eines Bilds von einem unter der Kontrolle des Angreifers stehenden Servers verwendet und dann das Logfile des Servers auf den Aufruf dieses Bilds gepr�ft werden.
    Statt der Manipulation normaler Parameter ist meist eine Manipulation von HTTP-Header-Feldern, z.B. des Referers, f�r einen Angriff zielf�hrender. Auch eine Manipulation der IP-Adresse ist einen Versuch wert, da oft davon ausgegangen wird, dass dieser Parameter nat�rlich eine IP-Adresse enth�lt und daher auf eine Pr�fung verzichtet wird. Ist der Angreifer nicht auf eine Antwort der Webanwendung angewiesen, kann er darin aber auch entweder eine falsche Adresse zur Verschleierung der Herkunft des Angriffs oder Schadcode einschleusen.
Die Suche beginnt...
About Security: Die komplette Serie

Wie bereits bei der Suche nach reflektierten XSS-Schwachstellen in About Security #158 und #159 beschrieben, wird f�r jeden Parameter ein Testmuster eingegeben. Doch statt nur die jeweils auf die Eingabe folgende Seite nach dem Testmuster zu durchsuchen, muss nun die gesamte Webanwendung durchsucht werden. Dabei kann es durchaus vorkommen, dass eine einmal gemachte Eingabe auf sehr vielen Seiten ausgegeben wird. Besonders h�ufig wird das z.B. bei Benutzernamen vorkommen: Einmal bei der Registrierung angegeben, erscheint der Name danach z.B. auf jeder personalisierten Seite der Webanwendung, in Benutzerlisten, bei den Kontakten anderer Benutzer, in Beitr�gen des Benutzers in Foren usw. � und das unter Umst�nden in verschieden Varianten, je nach angewandtem Filter. Entsprechend muss jedes Auftreten des Testmusters getrennt auf die M�glichkeit von XSS untersucht werden.

Vorsicht im Administrationsbereich

Au�er den normalen Seiten der Webanwendung m�ssen auch die des Administrationsbereichs auf das Auftauchen des Testmusters gepr�ft werden. Wie schon bei den Beispielen erw�hnt, sind solche F�lle f�r den Angreifer besonders interessant, da er dabei seinen Schadcode mit h�heren Benutzerrechten ausf�hren lassen kann. Ein etwas untypisches Beispiel daf�r ist eine XSS-Schwachstelle in vBulletin: Klickt ein Administrator einen pr�parierten Link an, kann sogar PHP-Code auf den Server eingeschleust werden.

Die weiteren Schritten zum Finden persistenter XSS-Schwachstellen erfahren Sie in der n�chsten Folge.

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