Cross-Site-Scripting und Script Injection verhindern: Ein kurzer Leitfaden

Cross-Site-Scripting und Script Injection verhindern

Ein kurzer Leitfaden

Stefan Friedli
by Stefan Friedli
time to read: 7 minutes

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:

Bezeichnung Darstellung HTML-Entity
Grösser-als-Zeichen < &lt;
Kleiner-als-Zeichen > &gt;
doppeltes Anführungszeichen &quot;
einfaches Anführungszeichen &#x27;
Kaufmännisches Und & &amp;
Schrägstrich / &#x2F;

Hinweise und Erläuterungen:

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:

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

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

You need support in such a project?

Our experts will get in contact with you!

×
Anthropomorphism

Anthropomorphism

Marisa Tschopp

Data Leakage Prevention

Data Leakage Prevention

Tomaso Vasella

Password Leak Analysis

Password Leak Analysis

Marc Ruef

WebSockets

WebSockets

Michael Schneider

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here