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 < und >
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.
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 Negativ-Beispiele
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!
