Content-Security-Policy: script-src Direktive
Baseline
Widely available
*
This feature is well established and works across many devices and browser versions. It’s been available across browsers since August 2016.
* Some parts of this feature may have varying levels of support.
Die HTTP Content-Security-Policy (CSP) script-src Direktive gibt gültige Quellen für JavaScript an. Dies umfasst nicht nur URLs, die direkt in <script>-Elemente geladen werden, sondern auch Dinge wie Inline-Skriptereignis-Handler (onclick) und XSLT-Stile, die Skriptausführung auslösen können.
| CSP-Version | 1 |
|---|---|
| Direktivtyp | Fetch-Direktive |
default-src Rückfall |
Ja. Wenn diese Direktive fehlt, sucht der Benutzeragent nach der
default-src Direktive.
|
Syntax
Content-Security-Policy: script-src 'none';
Content-Security-Policy: script-src <source-expression-list>;
Diese Direktive kann einen der folgenden Werte haben:
'none'-
Keine Ressourcen dieses Typs dürfen geladen werden. Die einfachen Anführungszeichen sind obligatorisch.
<source-expression-list>-
Eine durch Leerzeichen getrennte Liste von source expression Werten. Ressourcen dieses Typs dürfen geladen werden, wenn sie mit einem der angegebenen Quellen-Ausdrücke übereinstimmen. Für diese Direktive sind alle in der Fetch-Direktive-Syntax aufgeführten Quellen-Ausdrücke anwendbar.
Beispiele
>Ressourcen von vertrauenswürdigen Domains auf die Whitelist setzen
Angenommen, dieser CSP-Header erlaubt nur Skripte von https://example.com:
Content-Security-Policy: script-src https://example.com/
wird das folgende Skript blockiert und nicht geladen oder ausgeführt:
<script src="https://not-example.com/js/library.js"></script>
Beachten Sie, dass auch Inline-Ereignis-Handler blockiert sind:
<button id="btn" onclick="doSomething()">Click me</button>
Sie sollten diese durch addEventListener-Aufrufe ersetzen:
document.getElementById("btn").addEventListener("click", doSomething);
Wenn Sie Inline-Ereignis-Handler nicht ersetzen können, können Sie den 'unsafe-hashes'-Quellenausdruck verwenden, um sie zuzulassen.
Siehe Unsichere Hashes für weitere Informationen.
Externe Skripte mit Hashes auf die Whitelist setzen
Das Zulassen vertrauenswürdiger Domains, wie im obigen Abschnitt gezeigt, ist ein breit gefasster Ansatz, um die Orte zu spezifizieren, von denen Code sicher geladen werden kann. Dies ist ein pragmatischer Ansatz, insbesondere wenn Ihre Website viele Ressourcen verwendet und Sie zuversichtlich sind, dass die vertrauenswürdige Site nicht kompromittiert wird.
Eine alternative Methode besteht darin, erlaubte Skripte mithilfe von Datei-Hashes anzugeben.
Mit diesem Ansatz kann eine externe Datei in einem <script>-Element nur geladen und ausgeführt werden, wenn alle gültigen Hash-Werte in ihrem integrity-Attribut mit den erlaubten Werten im CSP-Header übereinstimmen.
Die Subressourcen-Integrität überprüft zudem, dass die heruntergeladene Datei den angegebenen Hash-Wert hat und daher nicht verändert wurde.
Dies ist sicherer als das Vertrauen in eine Domain, da Dateien nur verwendet werden, wenn sie unverändert sind, selbst wenn sie von einer kompromittierten Website geladen werden.
Es ist jedoch detaillierter und erfordert, dass Hash-Werte in CSP und Skriptelementen aktualisiert werden, wann immer die zugehörigen Skripte geändert werden.
Der CSP-Header unten zeigt den Ansatz.
Er erlaubt Skripte, für die der SHA384-Hash oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC oder der SHA256-Hash fictional_value ist.
Content-Security-Policy: script-src 'sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC' 'sha256-fictional_value'
Das nachstehende example-framework.js-Skript sollte geladen werden, da der Hash-Wert in seinem integrity-Attribut auch im CSP vorhanden ist (vorausgesetzt, die Datei hat diesen Hash tatsächlich nach dem Herunterladen!)
<script
src="https://example.com/example-framework.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>
Das integrity-Attribut kann mehrere Werte haben, wobei jeder einen Hash für die Datei angibt, die mit einem anderen Algorithmus berechnet wurde.
Damit ein externes Skript geladen wird, erfordert CSP, dass alle gültigen Hash-Werte im Attribut auch in der CSP script-src-Deklaration vorhanden sein müssen.
Deshalb würde das untenstehende Skript nicht geladen, da der zweite Hash nicht im obenstehenden CSP-Header vorhanden ist.
<script
src="https://example.com/example-framework.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC sha256-not-in-csp"
crossorigin="anonymous"></script>
Diese Regel gilt nur für gültige Hash-Werte. Werte, die vom Browser nicht als Hashes erkannt werden, werden ignoriert, sodass das folgende Skript geladen werden sollte:
<script
src="https://example.com/example-framework.js"
integrity="invalid-or-unsupported-hash sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>
Subressourcen-Integrität enthält weitere Informationen zur Berechnung von Hashes und zur Verwendung des integrity-Attributs.
Unsicheres Inline-Skript
Hinweis: Das Verbieten von Inline-Stilen und Inline-Skripten ist einer der größten Sicherheitsgewinne, die CSP bietet. Wenn Sie sie unbedingt verwenden müssen, gibt es einige Mechanismen, die sie erlauben. Hashes gelten für Inline-Skripte und Stile, aber nicht für Ereignis-Handler. Weitere Informationen finden Sie unter Unsichere Hashes.
Um Inline-Skripte und Stile zu erlauben, kann 'unsafe-inline', eine Nonce-Quelle oder eine Hash-Quelle, die mit dem Inline-Block übereinstimmt, angegeben werden.
Die folgende Content-Security-Policy erlaubt alle Inline-<script>-Elemente:
Content-Security-Policy: script-src 'unsafe-inline';
Das folgende <script>-Element wird von der Richtlinie erlaubt:
<script>
const inline = 1;
// …
</script>
Das Zulassen aller Inline-Skripte wird als Sicherheitsrisiko angesehen, daher wird empfohlen, stattdessen eine Nonce-Quelle oder eine Hash-Quelle zu verwenden. Um Inline-Skripte und Stile mit einer Nonce-Quelle zu erlauben, müssen Sie einen zufälligen Nonce-Wert (mithilfe eines kryptografisch sicheren Zufallstoken-Generators) generieren und ihn in der Richtlinie einfügen. Es ist wichtig zu beachten, dass dieser Nonce-Wert dynamisch generiert werden muss, da er für jede HTTP-Anfrage einzigartig sein muss:
Content-Security-Policy: script-src 'nonce-2726c7f26c'
Dann müssen Sie denselben Nonce im <script>-Element einfügen:
<script nonce="2726c7f26c">
const inline = 1;
// …
</script>
Alternativ können Sie Hashes aus Ihren Inline-Skripten erstellen. CSP unterstützt sha256, sha384 und sha512.
Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='
Beim Generieren des Hashs sollten die <script>-Tags nicht eingeschlossen werden, und es ist zu beachten, dass Groß- und Kleinschreibung sowie Leerzeichen wichtig sind, einschließlich führender oder nachgestellter Leerzeichen.
<script>
const inline = 1;
</script>
Unsichere Hashes
Richtlinien für Inline-Ressourcen mit Hashes wie script-src 'sha256-{HASHED_INLINE_SCRIPT}' erlauben Skripte und Stile anhand ihres Hashs, jedoch keine Ereignis-Handler:
<!-- Allowed by CSP: script-src 'sha256-{HASHED_INLINE_SCRIPT}' -->
<script>
const inline = 1;
</script>
<!-- CSP: script-src 'sha256-{HASHED_EVENT_HANDLER}'
will not allow this event handler -->
<button onclick="myScript()">Submit</button>
Anstatt 'unsafe-inline' zu erlauben, können Sie den 'unsafe-hashes'-Quellenausdruck verwenden, wenn der Code nicht auf gleichwertige addEventListener-Aufrufe aktualisiert werden kann.
Angenommen, eine HTML-Seite enthält den folgenden Inline-Ereignis-Handler:
<!-- I want to use addEventListener, but I can't :( -->
<button onclick="myScript()">Submit</button>
Der folgende CSP-Header lässt das Skript ausführen:
Content-Security-Policy: script-src 'unsafe-hashes' 'sha256-{HASHED_EVENT_HANDLER}'
Unsichere eval-Ausdrücke
Der 'unsafe-eval'-Quellenausdruck steuert mehrere Skriptausführungsmethoden, die Code aus Strings erstellen.
Wenn eine Seite einen CSP-Header hat und 'unsafe-eval' nicht mit der script-src Direktive angegeben ist, werden die folgenden Methoden blockiert und haben keine Wirkung:
eval()Function()-
Wenn ein String Literal an Methoden wie übergeben wird:
setTimeout("alert(\"Hello World!\");", 500); -
window.execScript()Nicht standardisiert (nur IE < 11)
Unsichere WebAssembly-Ausführung
Der 'wasm-unsafe-eval'-Quellenausdruck steuert die Ausführung von WebAssembly.
Wenn eine Seite einen CSP-Header hat und 'wasm-unsafe-eval' nicht in der script-src Direktive angegeben ist, wird WebAssembly daran gehindert, auf der Seite geladen und ausgeführt zu werden.
Der 'wasm-unsafe-eval' Quellenausdruck ist spezifischer als 'unsafe-eval', der sowohl die Kompilierung (und Instanziierung) von WebAssembly als auch die Nutzung der eval-Operation in JavaScript erlaubt.
Wenn das 'unsafe-eval' Quellenschlüsselwort verwendet wird, überschreibt dies das Vorkommen von 'wasm-unsafe-eval' in der CSP-Richtlinie.
Content-Security-Policy: script-src 'wasm-unsafe-eval'
strict-dynamic
Der 'strict-dynamic' Quellenausdruck gibt an, dass das Vertrauen, das explizit einem im Markup vorhandenen Skript gegeben wird, indem es mit einer Nonce oder einem Hash ausgestattet wird, auf alle von diesem Wurzelskript geladenen Skripte übertragen werden soll. Gleichzeitig werden jede Positivliste oder Quellenausdrücke wie 'self' oder 'unsafe-inline' ignoriert.
Zum Beispiel würde eine Richtlinie wie script-src 'strict-dynamic' 'nonce-R4nd0m' https://allowlisted.example.com/ das Laden eines Wurzelskripts mit <script nonce="R4nd0m" src="https://example.com/loader.js"> erlauben und dieses Vertrauen auf jedes von loader.js geladene Skript übertragen, aber das Laden von Skripten von https://allowlisted.example.com/ nicht erlauben, es sei denn, sie werden von einer vertrauenswürdigen Quelle geladen oder von einem Wurzelskript geladen, das mit einer Nonce ausgestattet ist.
Content-Security-Policy: script-src 'strict-dynamic' 'nonce-someNonce'
Oder:
Content-Security-Policy: script-src 'strict-dynamic' 'sha256-base64EncodedHash'
Es ist möglich, strict-dynamic auf eine rückwärtskompatible Weise bereitzustellen, ohne Benutzeragenten-Abfragen zu erfordern.
Die Richtlinie:
Content-Security-Policy: script-src 'unsafe-inline' https: 'nonce-abcdefg' 'strict-dynamic'
wird in Browsern, die CSP1 unterstützen, wie 'unsafe-inline' https:, in Browsern, die CSP2 unterstützen, wie https: 'nonce-abcdefg', und in Browsern, die CSP3 unterstützen, wie 'nonce-abcdefg' 'strict-dynamic'.
Spekulationsregeln erlauben
Um Spekulationsregeln in einem Skriptelement einzuschließen (siehe auch <script type="speculationrules">), müssen Sie die script-src Direktive mit einer der 'inline-speculation-rules' Quellen, einer Hash-Quelle oder einer Nonce-Quelle verwenden. Zum Beispiel:
Content-Security-Policy: script-src 'inline-speculation-rules'
Spezifikationen
| Specification |
|---|
| Content Security Policy Level 3> # directive-script-src> |