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.

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.

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.

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