Ausnahmsweise
Das Beispiel Content-Security-Policy "default-src 'self'" beschränkt das Nachladen sämtlicher Inhaltstypen auf die Domain der Seite (default-src 'self'). Das ist eine gute Ausgangssituation, um eventuell nötige Ausnahmen zu definieren. Soll eine Seite etwa auch von heise.de Skripte nachladen dürfen, fügt man eine entsprechende Skriptquelle (script-src) hinzu:
default-src 'self'; script-src http://heise.de
Der Aufbau ist leicht durchschaubar: Dem Header-Feld "Content-Security-Policy" folgt die sogenannte Direktive des Inhaltstyps und dahinter kommen die Parameter. Jede Direktive kann mehrere Parameter enthalten, die von Leerzeichen getrennt werden. Zumeist handelt es sich bei den Parametern schlicht um Listen der erlaubten Quellen. Das können vollständige URLs, Domains oder auch nur URL-Schemata wie http: oder https: sein. Letzteres erlaubt etwa das Erzwingen von HTTPS.
| Direktive |
Zweck |
| default-src | Standardquellen für Inhalte, sofern keine speziellere Direktive definiert wurde |
| connect-src | Ziele der JavaScript-Objekte XMLHttpRequest, WebSocket und EventSource |
| font-src | erlaubte Quellen für Schriftarten |
| frame-src | erlaubte Quellen für iFrames |
| img-src | erlaubte Quellen für Bilder |
| media-src | erlaubte Quellen für Video und Audio-Dateien |
| object-src | erlaubte Quellen für Flash-, Java-Applets und andere Plug-ins |
| script-src | erlaubte Quellen für JavaScript |
| style-src | erlaubte Quellen für Stylesheets |
| report-uri | Verstöße gegen die Policy werden hier berichtet |
| sandbox | Sandbox-Regeln analog zum sandbox-Attribut in HTML5 |
Es gibt die folgenden Direktiven:
Wildcards nach dem Muster http://*.heise.de sind laut Spezifikation erlaubt, man sollte sie allerdings ausschließlich im Header "Content-Security-Policy" benutzen – bei den X-Varianten ignoriert der Browser nämlich alles hinter dem Sternchen. Das Beispiel würde dazu führen, dass alle Domains erlaubt sind. Beim Definieren der Ausnahmeregeln ist das CSP-Bookmarklet von Brandon Sterne hilfreich. Es analysiert, welche Inhaltstypen der Browser beim Seitenaufruf von externen Quellen nachlädt und generiert daraus eine passende Whitelist.
Darüber hinaus gibt es Schlüsselwörter, die eigenwilligerweise in einfachen Anführungszeichen stehen müssen: 'self' bewirkt, dass der Inhaltstyp nur von der gleichen Quelle nachgeladen werden darf. Der Wert 'none' verbietet den Einsatz eines Inhaltstyps komplett.
Sobald eine Policy definiert wurde, führt der Browser keinen JavaScript-Code mehr aus, der direkt in den HTML-Code der Seite eingebettet ist – sogenannte Inline-Skripte. Das erfordert oft zwar Änderungen an der Seite (siehe "Umbaumaßnahmen"), ist aber auch durchaus sinnvoll: Es vereitelt die häufigste Form von XSS, die zu Beginn des Artikels geschildert wurde. Auch Inline-Stylesheets sind normalerweise durch CSP verboten, da Cyber-Ganoven darüber prinzipiell Daten abgreifen können. Mit 'unsafe-inline' schaltet man InlineSkripte (über die Direktive script-src) oder Inline-CSS (über style-src) wieder an. Wie sich aus dem führenden „unsafe-“ schon erschließt, sollte man von diesen Optionen nach Möglichkeit die Finger lassen.
Eine weitere Default-Einschränkung bei CSP ist das strikte Verbot der eval()-Funktion, die Zeichenketten in ausführbaren JavaScript-Code umwandelt – und damit das Einschleusen von Angriffscode erleichtert. Man schaltet eval() über das Schlüsselwort 'unsafe-eval' bei script-src wieder frei, wenn es sein muss. In der Firefox-Implementierung "X-Content-Security-Policy" werden die unsafe-Schalter nicht als Paramater der Direktiven angegeben, sondern nach folgendem Muster als "options" an die Policy gehängt:
X-Content-Security-Policy: default-src 'self'; options inline-script eval-script.
Inline-CSS ist bei der derzeitigen Firefox-Implementierung erlaubt.
Es sorgt für zusätzliche Sicherheit, den Einsatz nicht verwendeter Inhaltstypen durch den Wert 'none' zu verbieten. Wenn auf der Webseite etwa regulär keine Plug-ins zum Einsatz kommen, sorgt ein object-src 'none' dafür, dass der Browser unter keinen Umständen welche ausführt. Sollte es einem Angreifer beispielsweise gelingen, einen Java-Exploit in die Seite einzuschleusen, wird ein CSP-Browser diesen nicht starten. In Zukunft soll es die Möglichkeit geben, gezielt Plug-ins freizugeben.