Cross Site Scripting trotz htmlentities() [UPDATE]

Die PHP-Funktion htmlentities() soll vor Cross Site Scripting Angriffen schützen, denn sie kodiert Zeichen wie „<", ">„, sowie auch doppelte und einfache Anführungszeichen in deren HTML-Code-Entsprechung um. Dass allerdings die Kodierung der Anführungszeichen explizit eingeschaltet werden muss kann wohl als Designschwäche gesehen werden.

Eine weitere Schwachstelle beschrieb Chris Shifflet bereits 2005. Dabei behandelt htmlentites() UTF7-Codierte Zeichenketten nicht korrekt, was sich in manchen Fällen für XSS-Angriffe ausnutzen lässt.

Wie wird eine Zeichenkette konvertiert? Eine Zeichenkette wie diese:
<br />
<script>alert('XSS')</script><br />


wird durch htmlentities() umkodiert und wird so vom Browser nicht mehr ausgeführt. Der Cross-Site-Scripting-Angriff ist hier erstmal verhindert.
<br />
&lt;script&gt;alert(&#039;XSS&#039;)&lt;/script&gt;<br />


Anführungszeichen nicht benötigt

htmlentities() kodiert jedoch nicht andere Zeichen wie z.B. Klammern „(„, „)“ und Gleichheitszeichen „=“. Wird der Angriffscode in Zeichencodes konvertiert, lassen sich damit Sonderzeichen am Filter vorbei schleusen. Dieser Code passiert daher htmlentities() ohne Änderung:

Dies kann jetzt beispielsweise von den Angreifer an Stelle einer URL eingefügt werden.

Eventangriffe

Durch die Konvertierung der Anführungszeichen und spitzen Klammern kann der Angreifer den JavaScript-Code nicht in ein mit htmlentities() geschütztes Formularfeld einfügen oder aus diesen ausbrechen. Sind die Formularfeld-Attribute aber nicht durch einfache oder doppelte Anführungszeichen umschlossen – was nicht verpflichtend ist – dann kann der Angreifer, mit Hilfe der JavaScript-Events, seinen Schadcode einfügen:

Angriffsvektor:
<br />
5 onclick=eval(String.fromCharCode(97,108,101,114,116,40,39,88,83,83,39,41))<br />


Wird in ein Eingabefeld ohne umschließende Anführungszeichen zu einem JavaScript-Event:
<br />
<input type=text name=id value=5 onclick=eval(String.fromCharCode(97,108,101,114,116,40,39,88,83,83,39,41))><br />


Schutzmaßnahmen

• Eine Web-Firewall die Befehle wie „eval“ und „fromCharCode“ erkennt und abweist.
• Eine Validierung, die nur passende Eingaben zulässt:
  • http:// oder www. für Webseiten
  • Nur Zahlen für IDs
  • usw.
• Eine bessere Kodierung der Ausgabe.

Konzept eines Ausgabefilters auf Grundlage einer Whitelist

In [BSI01, S. 35] wird ein Beispiel für einen Whitelist-Filter für die Programmiersprache Perl skizziert. Kern des Filters ist ein regulärer Ausdruck, der selektiv nur folgende Zeichen unkodiert akzeptiert:

Tabelle 12: Whitelist – akzeptierte Zeichen

Zeichen, die nicht in dieser Liste stehen, werden hexadezimal kodiert und somit weiterhin korrekt in einen Webbrowser dargestellt. Jedoch können sie nicht länger zur Durchführung eines XSS-Angriffs verwendet werden. Für die Sicherheitsbibliothek SSEQ_LIB wurde die Funktion nach PHP portiert.

UPDATE 11.06.2009: Die neue Version der Funktion SEQ_OUTPUT kann auch multi-byte Zeichen korrekt kodieren. Ein Nachpflegen von Umlaute oder Sonderzeichen sollte damit entfallen.

(Code veraltet, siehe Update)
<br />
<?php
function SEQ_OUTPUT($string_ = '') {
    $string = preg_replace_callback('/(&#91;^a-zA-Z0-9_.-&#93;)/',
        create_function('$match_',
        'return sprintf("&#038;#x%04x;", ord($match_&#91;1&#93;));'),
         $string_);
    return $string;
}
?><br />

Abbildung 53: Whitelist-Filter für PHP-Ausgabe

Der oben gezeigte Angriffscode wird nun konvertiert:
<br />
5 onclick=eval(String.fromCharCode(97,108,101,114,116,40,39,88,83,83,39,41))</p>
<p>wird zu:</p>
<p>5&#x0020;onclick&#x003d;eval&#x0028;String.fromCharCode&#x0028;97&#x002c;108&#x002c;101&#x002c;114&#x002c;116&#x002c;40&#x002c;39&#x002c;88&#x002c;83&#x002c;83&#x002c;39&#x002c;41&#x0029;&#x0029;<br />


Da mit der Funktion SEQ_OUTPUT() auch Zeichen wie Klammern „(„, „)“ und Gleichheitszeichen „=“ konvertiert werden, wird der Cross-Site-Scripting-Angriff hier gestoppt.

Anmerkung: Eine derart konvertierte Zeichenkette wird von einem Formular in encodierter Form gesendet, kommt also beim Skript wieder in „ungeschützter“ Form an. In der weiteren Verarbeitung muss sie also ebenfalls mit der Funktion SEQ_OUTPUT() behandelt werden.