Mittwoch, 4. Juli 2012


Topthema

Donnerstag, 5. Juni 2008 | Topthema

About Security #158: Schwachstellensuche: Einfaches XSS

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

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:

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

  • 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
About Security: Die komplette Serie

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.

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