Channel Security

Ab dieser Folge geht es um Angriffe über vom Benutzer gelieferte Daten. Den Anfang macht die Suche nach Cross-Site-Scripting-Schwachstellen.

Schritt 5: XSS-Schwachstellen

Cross-Site-Scripting-Schwachstellen wurden bereits in About Security #14 und #15 vorgestellt und dann ab #129 vertieft. Was Cross-Site Scripting ist und wie entsprechende Angriffe funktionieren, erfahren Sie dort. Im Folgenden dreht sich alles um die Frage, wie man solche Schwachstellen findet.

Voraussetzungen für XSS

Die erste Voraussetzung für Cross-Site-Scripting-Angriffe ist eine fehlende oder mangelhafte Prüfung von Benutzereingaben: Immer, wenn HTML- oder JavaScript-Code eingegeben werden kann, besteht Gefahr. Unerwünschte Tags müssen ausgefiltert werden, bevor die eingegebenen Daten ausgegeben oder von der Webanwendung gespeichert werden. Und damit sind wir schon bei der zweiten Voraussetzung: Benutzereingaben müssen an Benutzer ausgegeben werden. Ob das der gleiche Benutzer oder ein anderer ist, ist dabei erst einmal unerheblich. Diese Unterscheidung wird erst dann interessant, wenn es um die Durchführbarkeit eines Angriffs geht. Dann gibt es einige mögliche Kombinationen:

• Die Daten werden über den URL übertragen und in der aufgebauten Webseite an den Benutzer zurückgegeben. Formal bedeutet das, der Benutzer bekommt die von ihm eingegebenen Daten zurückgeliefert. Das lässt sich für einen XSS-Angriff ausnutzen, es handelt sich um das klassische reflektierte Cross-Site Scripting: Der Angreifer schiebt dem Opfer einen präparierten URL unter, und wenn das Opfer den URL aufruft, wird der eingeschleuste Code von der Webanwendung in die ausgelieferter Seite integriert und im Webbrowser des Opfers ausgeführt.
• Die Daten werden auf dem Webserver gespeichert, z.B. in einer Datenbank (genauso gut können die Daten aber auch in einer Datei gespeichert werden). Wird danach ein so präparierter Eintrag aufgerufen, wird der eingeschleuste Code im Webbrowser des Aufrufers ausgeführt. Handelt es sich dabei um einen anderen Benutzer als den, der die Daten eingegeben hat, handelt es sich um persistentes XSS (auch JavaScript Injection genannt).
  Kann der präparierte Eintrag nur vom ursprünglichen Benutzer, d.h. dem Angreifer, aufgerufen werden, ist streng genommen kein XSS-Angriff möglich (bzw. nur ein sehr nutzloser Angriff gegen sich selbst). Trotzdem sollten die Daten auch in diesem Fall geprüft werden. Zum einen aus Prinzip, ungeprüfte Benutzereingaben stellen immer eine potenzielle Gefahr dar. Zum anderen, weil eventuell doch andere Benutzer an diese Daten gelangen könnten. Das könnte z.B. passieren, wenn ein Administrator einen Eintrag nach einer Beschwerde prüft. Niemand hindert den Angreifer daran, Schadcode in eine nur für ihn zugängliche Seite einzuschleusen und dann einen Administrator wegen einer angeblichen Fehlfunktion zum Betrachten der Seite zu bewegen.

Gefährliche Eingaben

Potenziell sind alle Benutzereingaben für Cross-Site Scripting brauchbar. Außer den klassischen Fällen wie Suchwörtern, 404-Fehlermeldungen, Kommentaren und Forenbeiträgen kann der XSS-Code z.B. auch über Benutzernamen, SQL-Fehlermeldungen oder manipulierte HTTP-Header eingeschleust werden. Alles Daten, die vom Client geliefert und daher vom Benutzer manipuliert werden können, müssen auf eingeschleusten XSS-Code geprüft werden, bevor sie direkt an den Benutzer zurückgegeben oder für eine spätere Verwendung von der Webanwendung gespeichert werden. Dabei ist mit Benutzer nicht nur der eigentliche Benutzer der Webanwendung gemeint. Auch Administratoren, die für normale Benutzer nicht zugängliche Daten wie z.B. Logfiles in einem Webbrowser betrachten, können das Opfer von XSS-Angriffen werden.

Schwachstellen finden

Finden keinerlei Prüfungen statt, können potenziell gefährliche Parameter durch das simple Eingeben eines Testcodes wie z.B. des altbekannten

<script>alert('XSS')</script>

überprüft werden. Werden mehrere Parameter auf einmal getestet, kann zur Unterscheidung der Parameter deren jeweiliger Name in die Meldung übernommen werden:

http://www.beispiel.example/index.php?name=<script>alert('XSS über name')</script>
&password=<script>alert('XSS über password')</script>

Außer Formularfeldern (einschließlich versteckten) und URL-Parametern müssen auch Cookies und, sofern von der Webanwendung verwendet, HTTP-Header geprüft werden.

Außer der klassischen Alertbox können auch einfach erkennbare Testmuster eingegeben und die ausgegebenen Seiten darauf überprüft werden. Die Zeichenkette ##XSS-Test## fällt beispielsweise relativ gut auf und lässt sich auch leicht über eine Suchfunktion finden. Außer auf dieser Seite kann ich mir jedenfalls keine Seite vorstellen, die dieses Muster in der normalen Seite enthält.

Mit diesen Methoden findet man die einfachen Fälle von XSS-Schwachstellen. Wie man kniffligere Versionen erkennt, 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