Donnerstag, 30. August 2012


Topthema

Donnerstag, 26. Juni 2008 | Topthema

About Security #161: Schwachstellensuche: XSS verhindern

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

Werden Cross-Site-Scripting-Schwachstellen (wie in About Security #158, #159 und #160 beschrieben) gefunden, m�ssen die nat�rlich behoben werden. Dazu m�ssen alle Eingaben vor ihrer Verwendung gepr�ft und ggf. verworfen oder gefiltert werden. Die entsprechenden Funktionen m�ssen nur einmal implementiert werden und k�nnen dann auf alle betroffenen Parameter angewendet werden. Worauf Sie dabei achten m�ssen, erfahren Sie in dieser Folge.

Einfach, aber nicht unbedingt sicher: Gef�hrliche Zeichen filtern

Die einfachste L�sung ist das rigorose Ausfiltern der potenziell gef�hrlichen Zeichen wie <, >, ", ', / und :. Soll die Eingabe von HTML-Code, z.B. Auszeichnungs- oder Formatierungsanweisungen, m�glich sein, kann stattdessen z.B. BBCode verwendet werden. F�r fett gedruckten Text wird dann statt der HTML-Anweisung <b>fett</b> die BBCode-Anweisung [b]fett[/b] verwendet, < und > werden nicht mehr ben�tigt und k�nnen gel�scht oder umgewandelt werden. Werden alle < und > durch ihre HTML-Entities &lt; und &gt; ersetzt, k�nnen keine HTML-Tags wie z.B. <script>..</script> eingeschleust werden. Wie Sie in About Security #160 gesehen haben, sind in bestimmten F�llen aber auch ohne diese Zeichen Angriffe m�glich.

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

Schwieriger, aber nicht zwingend sicherer: Komplette Tags filtern

Ein weiterer Ansatz zum Pr�fen und Filtern der Eingaben ist das Ausfiltern kompletter Tags anhand von Negativlisten. Damit wirklich kein Schadcode eingeschleust werden kann, m�ssen dabei alle m�glicherweise gef�hrlichen Tags und alle m�glichen Tarnungen dieser Tags erfasst werden. Naturgem�� kann so eine Liste nie vollst�ndig sein. Wenn man denkt, alle m�glichen Tags und deren Variationen und Kombinationen gefunden zu haben, findet bestimmt irgendjemand eine neue Methode, funktionsf�higen Code an der Negativliste vorbeizuschleusen.

Der beste Ansatz: Nur Erw�nschtes durchlassen

Allgemein besser, da einfacher zu warten, ist eine Positivliste aller zul�ssigen Eingaben. Wenn HTML erlaubt ist, d�rfen nur korrekt formatierte Tags akzeptiert werden. Alles, was nicht wohlgeformt ist, k�nnte in irgendeinem Webbrowser zu unerw�nschte Reaktionen f�hren.

Was nicht auf der Positivliste steht, wird zur�ckgewiesen oder verworfen. Wobei sich �ber die Frage, ob die Eingabe kommentarlos verworfen oder mit einer Fehlermeldung abgelehnt wird, streiten l�sst. F�r beides gibt es gute Gr�nde: Eine ausf�hrliche Fehlermeldung hilft dem Benutzer, das unerw�nschte Zeichen aus seiner Eingabe zu entfernen. M�chte er "Hier ist a<b" eingeben und die Eingabe wird wegen des <-Zeichens nicht akzeptiert, kann er das Zeichen ausschreiben und "Hier ist a kleiner als b" erfolgreich eingeben. Ein Angreifer erf�hrt durch die gleiche Fehlermeldung aber, woran sein Angriff bei diesem Versuch gescheitert ist und kann daraus eventuell Schl�sse f�r weitere m�gliche Variationen ziehen. Mein Rat ist in diesem Fall, der Benutzerfreundlichkeit den Vorzug zu geben. Ein Angreifer l�sst sich von einer allgemeinen Meldung wie z.B. "Unerw�nschte Zeichen "<b" entdeckt, Eingabe nicht zul�ssig" nicht abhalten, ein Benutzer von einem mehrmaligen allgemeinen "Eingabe nicht zul�ssig" aber schnell vergraulen.

Eingaben vorbereiten

Im Folgenden wird davon ausgegangen, dass mit einer Negativliste gearbeitet wird. Beim Einsatz eine Positivliste er�brigt sich die Vorbereitung der Eingabe: Entweder wird sie ohne �nderung akzeptiert, oder sie wird gar nicht akzeptiert.

About Security: Die komplette Serie

Wie Sie in About Security #160 gesehen haben, k�nnen Filter in manchen F�llen durch ungew�hnliche Schreibweisen oder Formatierungen �berlistet werden. Entsprechend sorgf�ltig m�ssen die Eingaben auf die Pr�fung vorbereitet werden: Die Eingaben m�ssen in den passenden Zeichensatz (Charset) umgewandelt und Gro�- und Kleinschreibung vereinheitlicht werden. �berfl�ssige Whitespace-Zeichen (normale Leerzeichen, Tabulator-Zeichen, Nullbytes etc.) m�ssen entfernt und die verbleibenden in ein einheitliches Zeichen umgewandelt werden. Erst wenn die Eingaben derartig vereinheitlicht wurden, k�nnen sie mit der Negativliste verglichen werden.

Weitere Negativbeispiele

Zum Abschluss noch einige weitere Beispiele, wie ein Angreifer nachl�ssig programmierte Schutzfunktionen umgehen kann:

  • Funktionen, die nur in <..> eingeschlossene Tags erkennen, k�nnen durch unvollst�ndige Tags umgangen werden, die in manchen Browsern trotz ihres Fehlers interpretiert werden, z.B.
    <img src="" onerror=alert(xss!)
  • Funktionen, die ein Nullbyte als Zeilenende interpretieren und darauf folgenden Text ignorieren, k�nnen durch ein URL-kodiertes Nullbyte vor dem Schadcode get�uscht werden:
    harmlos%00<script>alert('XSS')</script>
  • Wie schon in About Security #159 erw�hnt, kann der Angriff auch �ber eine andere als die erwartete �bertragungsmethode erfolgen. Es muss also darauf geachtet werden, das der richtige Parameter gepr�ft wird, n�mlich der, der hinterher auch verwendet wird.

Bisher ging es im Wesentlichen um reflektiertes Cross-Site Scripting. In der n�chsten Folge geht es um die Suche nach persistenten und DOM-basierten Cross-Site-Scripting-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"

(rl)

Kommentare

Folgende Links könnten Sie auch interessieren