Channel Security

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.

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

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.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Schwachstellensuche – III. Angriffe über vom Benutzer gelieferte Daten: XSS"

• About Security #158: Schwachstellensuche: Einfaches XSS
• About Security #159: Schwachstellensuche: XSS trotz Filter
• About Security #160: Schwachstellensuche: XSS finden
• About Security #161: Schwachstellensuche: XSS verhindern
• About Security #162: Schwachstellensuche: Persistentes XSS (1)
• About Security #163: Schwachstellensuche: Persistentes XSS (2)
• About Security #164: Schwachstellensuche: Persistentes XSS (3)
• About Security #165: Schwachstellensuche: DOM-basiertes XSS