Bilder, Fonts und andere

Neben externen Skripten ermöglicht es Content Security Policy auch zu definieren, aus welchen Quellen Elemente wie Bilder (img-src), Schriftarten (font-src), Frames (frame-src) und zahlreiche andere Arten von Inhalten eingefügt werden können. Eine vollständige Übersicht findet sich in den Spezifikationen der Content Security Policy. Verschiedene Direktiven können durch Strichpunkte (;) abgetrennt werden. Ein Beispiel wäre etwa script-src 'self';img-src 'self' images.example.com. Hier wäre Script-Code nur von der eigenen Domain zulässig, Bilder können zusätzlich von der Domain images.example.com nachgeladen werden.

Als besondere Direktive existiert noch default-src, diese bezieht sich auf sämtliche Inhalte, die extern eingebunden werden können. Eine später aufgelistete Direktive überschreibt immer alle vorherigen. So könnte man etwa mit default-src 'self';script-src 'self' script.example.com sämtliche Inhalte nur vom eigenen Server zulassen, lediglich Script-Code darf vom externen Server script.example.com eingebunden werden.

Die Standardeinstellung für alle Medieninhalte ist aber, dass diese grundsätzlich zugelassen werden.

Sonderfall Inline-Code

Einen Spezialfall stellt sogenannter Inline-Javascript-Code dar. Üblicherweise kann an jeder Stelle in einem HTML-Dokument beliebiger Javascript-Code stehen, dazu gibt es die Möglichkeit, HTML-Elementen bei bestimmten Ereignissen wie etwa einem Klick Javascript-Code zuzuweisen. Das folgende, triviale Beispiel etwa würde ein Pop-up öffnen:

<script>alert(1)</script>

Derartiger Inline-Code wird in Content Security Policy mit einem speziellen Keyword 'unsafe-inline' gesteuert. Da Inline-Code üblicherweise für die meisten Cross-Site-Scripting-Angriffe verantwortlich ist, sollte dieser unbedingt vermieden werden. Obiges Beispiel müsste man hierzu in eine externe Datei auslagern:

<script src="test.js"></script>

Die Datei test.js enthält dann den gewünschten Code - im genannten Beispiel das simple alert(1).

Für CSS-Formatierungen gilt Ähnliches. Ohne das Keyword 'unsafe-inline' bei style-src sind direkte Angaben von Formatierungen in HTML-Code nicht mehr möglich, sie müssen in eine separate CSS-Datei ausgelagert werden.

Ausführen von Code in Code

Javascript bietet die Möglichkeit, mit dem Kommando eval() innerhalb von Javascript-Code einen String wiederum als Code auszuführen. Das kann in manchen Fällen nützlich sein, jedoch birgt es auch ein Sicherheitsrisiko. Wenn ein Entwickler einem eval-Befehl ein Stück Code übergibt, das eine Nutzereingabe enthält, ergibt sich hier wiederum eine Cross-Site-Scripting-Lücke.

Aus diesem Grund lässt sich mit Content Security Policy die Ausführung von Code mit eval() und anderen Befehlen, die Vergleichbares ermöglichen, deaktivieren. Gesteuert wird dies durch das Keyword 'unsafe-eval'.

Berichte an den Anwendungsentwickler

Wenn Content Security Policy die Ausführung von Code oder das Einfügen eines Elements verhindert, ist dies ein Zeichen dafür, dass eine Lücke oder ein Bug in einer Anwendung existieren. Daher gibt es für Webentwickler die Möglichkeit, sich informieren zu lassen, wenn eine entsprechende Codesperre greift. Im Header kann man eine URL angeben, an die vom Browser automatisch Berichte als POST-Daten gesendet werden.

Gekennzeichnet wird diese Berichts-URL durch das Stichwort report-uri. Ein Beispielheader sähe etwa so aus: default-src 'self'; script-src 'self' 'script.example.com'; report-uri /reportxss.php. Unter der angegebenen URL sollte dann ein serverseitiges Script laufen, welches die empfangenen Daten an den Webentwickler weiterleitet oder in ein Logfile schreibt.

Microsoft und Opera warten ab

Mit Content Security Policy existiert nun ein ausgefeiltes Werkzeug, um Cross-Site-Scripting-Angriffe zu unterbinden. Bislang wird es jedoch nur von Chrome und Firefox standardmäßig unterstützt, in anderen Browsern ist es entweder unvollständig oder nur über experimentelle Headernamen nutzbar. Der Internet Explorer unterstützt bisher nur ein spezielles Subfeature von Content Security Policy. Opera unterstützt das Konzept bisher überhaupt nicht. Apples Safari hat bislang wie oben erwähnt noch einen eigenen, experimentellen Header-Namen.

Weitere Informationen zum Einsatz von Content Security Policy lassen sich im englischsprachigen Tutorial An Introduction to Content Security Policy des Google-Entwicklers Mike West finden.