Wie konfiguriert man die Content Security Policy?
Nachdem im ersten Teil des Blogs die Wichtigkeit einer Content Security Policy betont wurde, damit beim Besuch einer Website keine “bösen” Ressourcen geladen werden - geht es jetzt in diesem zweiten Teil konkret um die Konfiguration der CSP.
Die vielen Konfigurationsmöglichkeiten der Content Security Policy erlauben einen genauen Zuschnitt auf den Anwendungsfall. Prinzipiell soll so wenig wie möglich, aber so viel wie nötig, durch die Content Security Policy zugelassen werden. Die Konfiguration der Content Security Policy erfolgt über sogenannte Direktiven, über die bereichsweise eingeschränkt werden kann, woher die Ressourcen kommen dürfen.
Einige wichtige Direktiven sind die folgenden:
- script-src – bestimmt, woher JavaScript-Code kommen darf
- style-src – bestimmt, woher CSS-Code kommen darf
- img-src – bestimmt, woher Bilder kommen dürfen
- media-src – bestimmt, woher Medien für <audio>- und <video>-Tags kommen dürfen
- font-src – bestimmt, woher Dateien für Schriften kommen dürfen
- default-src – dient als Fallback, falls sonst keine Direktive angegeben wurde
Neben den aufgelisteten Direktiven gibt es noch weitere, jedoch reichen die genannten für ein paar Use Cases schon aus.
Für jede der Direktiven kann man nun bestimmen, woher die Ressourcen kommen dürfen. Schauen wir uns das am Beispiel einer Content Security Policy in einem <meta>-Tag mit der script-src-Direktive genauer an:
<meta http-equiv="Content-Security-Policy" content="script-src ‚self‘ https://code.jquery.com">Diese Content Security Policy erlaubt JavaScript-Code von folgenden 2 Orten:
- durch ‚self‘ - von der eigenen Origin (wenn man https://referenzen.my-page.com/musterfirma besucht, ist die Origin https://referenzen.my-page.com)
- durch https://code.jquery.com – von https://code.jquery.com, um z.B. das fertig gebaute jquery-JavaScript herunterzuladen, falls das durch ein CDN eingebunden ist.
JavaScript-Code, der beispielsweise direkt in einem Tag vorkommt, ist so nicht mehr ausführbar. Falls ein Angreifer es schafft, einen Tag auf der Website einzubinden, kann damit verhindert werden, dass eingeschleuster JavaScript-Code Schaden anrichtet.
Neben ‚self‘, um Ressourcen von der aktuellen Origin zu erlauben, gibt es noch andere „Schlüsselwörter“, z.B.:
- ‚all‘ – erlaubt alle Ressourcen
- ‚none‘ – verbietet die Verwendung der Ressource
Auch können beliebig viele URLs als Ausnahmen angefügt werden. Neben einer exakten URL (wie bei unserem Beispiel https://code.jquery.com), können auch Wildcards in der URL sowie Ports spezifiziert werden, z.B.:
- https://*.jquery.com – Erlaubt Ressourcen von allen Subdomains von jquery.com, die https verwenden, jedoch nicht jquery.com selbst.
- www.jquery.com:443 – Erlaubt Ressourcen, die von www.jquery.com vom Port 443 kommen, unabhängig davon, ob über https oder http übertragen wird.
Wichtig ist, dass für alle benötigten Ressourcen eine Ausnahme angelegt wird. Ansonsten kann es passieren, dass Features auf der Website nicht mehr funktionieren. Wenn beispielsweise die Cookie-Meldung durch einen externen Service bereitgestellt wird und dieser eine JavaScript-Datei auf der Website fordert, kann durch eine fehlende Ausnahme die JavaScript-Datei nicht geladen werden. Dann wird die Cookie-Meldung nicht angezeigt.
Abschließend noch zwei hilfreiche Webseiten:
Der CSP-Generator kann dabei unterstützen, die Content Security Policy nach den eigenen Wünschen zu gestalten: https://report-uri.com/home/generate
Mit dem CSP-Evaluator kann geprüft werden, wie viel Sicherheit eine Content Security Policy bringt. Außerdem werden einem Tipps gegeben, wie die Sicherheit erhöht werden kann: https://csp-evaluator.withgoogle.com/
Blogserie Content Security Policy
