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

Cross-Site-Scripting und Script Injection verhindern

Ein kurzer Leitfaden

Stefan Friedli
von Stefan Friedli
Lesezeit: 7 Minuten

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.

Über den Autor

Stefan Friedli

Stefan Friedli gehört zu den bekannten Gesichtern der Infosec Community. Als Referent an internationalen Konferenzen, Mitbegründer des Penetration Testing Execution Standard (PTES) und Vorstandsmitglied des Schweizer DEFCON Group Chapters trägt er aktiv zum Fortschritt des Segmentes bei.

Links

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

×
TIBER-EU Framework

TIBER-EU Framework

Dominik Altermatt

Vertrauen und KI

Vertrauen und KI

Marisa Tschopp

Datenverschlüsselung in der Cloud

Datenverschlüsselung in der Cloud

Tomaso Vasella

Cyber Threat Intelligence

Cyber Threat Intelligence

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv