XSS und Script Injection Schwachstellen gehören nach wie vor zu den verbreitesten Problemen in Webapplikation bis dato. Diese zu mitigieren wird oft als trivial verstanden, aber ebenso oft erfolgen Gegenmassnahmen nur teilweise korrekt, was in einem nicht zu vernachlässigenden Restrisiko resultieren kann. Es ist nicht ausreichend, ausschliesslich spezifische Zeichen zu enkodieren (z.B. wie htmlentities) oder gewisse Zeichen komplett zu filtern. Die nachfolenden Punkte zeigen auf, welche Schritte berücksichtigt werden sollten, um eine korrekte, funktionale Eingabevalidierung zu implementieren. Diese Empfehlungen sind als Grundlage zu verstehen, um individuelle, auf die jeweilige Applikation zugeschnittene Massnahmen definieren und umsetzen zu können.

In Content-Elementen (div und body)

<div>Ihre Eingabe lautet: USER DATA</div>

Es muss sichergestellt werden, dass signifikante Zeichen als HTML Entitäten enkodiert werden, damit der Benutzer keine Daten ausserhalb des Datenkontextes injizieren kann. Die signifikanten Zeichen lauten:

Hinweise und Erläuterungen:

• Der Forward Slash (/) wird in Closing Tags genutzt, weshalb es Sinn macht und gemeinhin als gute Praxis betrachtet wird, ihn ebenfalls zu enkodieren.
• Das einfache Anführungszeichen (') wird oft mit der Named Character Reference ' enkodiert. Dies ist inkorrekt: ' wird zwar in XML 1.0 definiert, ist aber kein gültiges HTML Symbol. Zwar sind die meisten Browser in der Lage, damit problemlos umzugehen, der korrekte Weg ist aber der oben illustrierte mittels '

In regulären HTML-Atributen

Die nachfolgende Regel gilt nicht für komplexe Attribute wie JavaScript Event Handler (z.B. onmouseover) oder Style-Attribute. Siehe dafür den nachfolgenden Abschnitt.

<input value="USERDATA" />
<input value='USERDATA' />
<input value=USERDATA />

Wie aus dem Beispiel ersichtlich wird, existieren hier mehrere mögliche Fälle. Oft werden, obwohl dies inkorrekt ist, Attribute ohne Anführungszeichen verwendet. Speziell in diesem Fall könnte ein Angreifer sehr einfach aus dem Kontext des Attributes ausbrechen.

Aus diesem Grund sollten hier alle Zeichen, die nicht alphanumerisch sind und einen ASCII-Wert unter 256 haben im Format &#xHH; encodiert werden. Der Grund liegt hier im vorgängig beschriebenen Umstand, dass oftmals Attribute ohen Anführungszeichen verwendet werden, aus denen mit verschiedensten Zeichen (inklusive einem simplen Leerzeichen) ausgebrochen werden kann. Werden Attribute korrekt von Anführungszeichen eingeschlossen, so kann nur mit einem korrespondierenden Anführungszeichen daraus ausgebrochen werden. Trotzdem empfiehlt es sich hier, auf Nummer sicher zu gehen.

In Javascript-Funktionen oder CSS-Definitionen

<script>alert('USERDATA');</script>

Das Verwenden unvertrauenswürdiger Daten innerhalb von Javascript-Blöcken ist enorm gefährlich und sollte mit höchster Vorsicht vorgenommen werden. Werden Werte explizit als Daten innerhalb eines Skripts benötigt, so sollten wiederum alle Zeichen, die nicht alphanumerisch sind und einen ASCII-Wert unter 256 haben im Format &#xHH; enkodiert werden. Allgemein sollte diese Praxis aber, wann immer möglich, vermieden werden.

Die goldene Regel

Die Versuchung für viele Entwickler ist gross, einen einfacheren Weg zu wählen und ein simples HTML Encoding anzustreben. Während jede Massnahme besser ist, als gar keine Massnahmen, so ist dies leider kein gangbarer Weg. Die obenstehenden Empfehlungen geben wertvolle Grundlagen, grundsätzlich sollte aber die Prämisse lauten:

Unvertrauenswürdige Daten sollten nie an Orten platziert werden, die nicht explizit dafür vorgesehen und mit entsprechenden Massnahmen geschützt sind.

So ist es problemlos möglich, die Verwendung von Daten innerhalb eines div-Tags akkurat zu schützen. Es ist aber vergleichsweise schwierig, das selbe innerhalb eines script-Tags zu erreichen.

Jeder Kontext, in dem derartige Daten genutzt werden sollen, muss sorgfältig geprüft werden. Niemals aber sollten unvertrauenswürdige Daten in folgenden Kontexten eingesetzt werden:

• in einem HTML Kommentar
• in einem Attributs-Namen
• in einem Tag-Namen
• direkt in einem Script

Die obenstehenden Empfehlungen decken sich weitgehend mit den Empfehlungen des OWASP Projektes und dienen der scip AG als offizielle Empfehlung.

About the Author

Stefan Friedli is a well-known face among the Infosec Community. As a speaker at international conferences, co-founder of the Penetration Testing Execution Standard (PTES) as well as a board member of the Swiss DEFCON groups chapters, he still contributes to push the community and the industry forward.

Links

• http://www.w3.org/TR/xhtml1/#C_16