Subresource Integrity

Wie Subresource Integrity hilft

Websites entscheiden sich manchmal dafür, auf einen Drittanbieter wie ein Content Delivery Network (CDN) zu verzichten, um einige ihrer Ressourcen zu hosten, anstatt alle ihre Ressourcen selbst zu hosten. Zum Beispiel könnte ein von https://example.com geliefertes Dokument eine Ressource von einem anderen Ort beinhalten:

<script src="https://not-example.com/script.js"></script>

Dies birgt ein Risiko, denn wenn ein Angreifer die Kontrolle über den Drittanbieter-Host erlangt, kann der Angreifer beliebigen schädlichen Inhalt in seine Dateien injizieren (oder die Dateien komplett ersetzen) und somit potenziell auch Seiten angreifen, die Dateien von dort abrufen.

Subresource Integrity ermöglicht es Ihnen, einige Risiken solcher Angriffe zu mindern, indem sichergestellt wird, dass die Dateien, die Ihre Webanwendung oder Ihr Webdokument abruft, geliefert wurden, ohne dass ein Angreifer zusätzlichen Inhalt in diese Dateien eingefügt hat — und ohne, dass an diesen Dateien sonstige Änderungen jeglicher Art vorgenommen wurden.

Verwendung von Subresource Integrity

Sie verwenden die Subresource Integrity-Funktion, indem Sie einen Base64-codierten kryptografischen Hash einer Ressource (Datei) angeben, die Sie dem Browser zum Laden anweisen, im Wert des integrity-Attributs eines <script>-Elements oder eines <link>-Elements mit rel="stylesheet", rel="preload" oder rel="modulepreload".

Ein integrity-Wert beginnt mit mindestens einem String, wobei jeder String ein Präfix enthält, das einen bestimmten Hash-Algorithmus angibt (derzeit sind die erlaubten Präfixe sha256, sha384 und sha512), gefolgt von einem Bindestrich und endet mit dem eigentlichen Base64-codierten Hash.

Beispiel integrity-String mit Base64-codiertem sha384-Hash:

sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC

oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC ist der "Hash"-Teil, und das Präfix sha384 zeigt an, dass es sich um einen sha384-Hash handelt.

Werkzeuge zur Generierung von SRI-Hashes

SRI Hash Generator

Der SRI Hash Generator ist ein Online-Tool, das Sie verwenden können, um SRI-Hashes zu generieren.

Verwendung von OpenSSL

Sie können SRI-Hashes über die Befehlszeile mit OpenSSL generieren, mit einem Befehl wie:

cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A

In einer Windows-Umgebung können Sie ein Tool zur Generierung von SRI-Hashes mit dem folgenden Code erstellen:

@echo off
set bits=384
openssl dgst -sha%bits% -binary %1% | openssl base64 -A > tmp
set /p a= < tmp
del tmp
echo sha%bits%-%a%
pause

Um diesen Code zu verwenden:

1. Speichern Sie diesen Code in einer Datei namens sri-hash.bat im Windows-SendTo-Ordner Ihrer Umgebung (zum Beispiel C:\Users\USER\AppData\Roaming\Microsoft\Windows\SendTo).
2. Klicken Sie mit der rechten Maustaste auf eine Datei im Explorer, wählen Sie Senden an... und dann sri-hash. Sie werden den Integritätswert in einem Befehlsfenster sehen.
3. Wählen Sie den Integritätswert aus und klicken Sie mit der rechten Maustaste, um ihn in die Zwischenablage zu kopieren.
4. Drücken Sie eine beliebige Taste, um das Befehlsfenster zu schließen.

Verwendung von shasum

Sie können SRI-Hashes mit shasum mit einem Befehl wie diesem generieren:

shasum -b -a 384 FILENAME.js | awk '{ print $1 }' | xxd -r -p | base64

• Der Pipe-Schritt xxd konvertiert die hexadezimale Ausgabe von shasum in Binärdaten.
• Der Pipe-Schritt awk ist notwendig, weil shasum den gehashten Dateinamen in seiner Ausgabe an xxd übergibt. Dies kann katastrophale Folgen haben, wenn der Dateiname gültige Hex-Zeichen enthält — xxd würde das dann ebenfalls dekodieren und an base64 übergeben.

Cross-Origin Resource Sharing und Subresource Integrity

Bei der Überprüfung der Subresource-Integrität einer Ressource, die von einem anderen Ursprung als dem Dokument, in dem sie eingebettet ist, bereitgestellt wird, prüfen Browser die Ressource zusätzlich mit Cross-Origin Resource Sharing (CORS), um sicherzustellen, dass der Ursprung, der die Ressource bereitstellt, es erlaubt, sie mit dem anfragenden Ursprung zu teilen. Daher muss die Ressource mit einem Access-Control-Allow-Origin-Header bereitgestellt werden, der es erlaubt, die Ressource mit dem anfragenden Ursprung zu teilen; zum Beispiel:

Access-Control-Allow-Origin: *

Wie Browser Subresource Integrity behandeln

Browser behandeln SRI, indem sie Folgendes tun:

1. Wenn ein Browser auf ein <script>- oder <link>-Element mit einem integrity-Attribut stößt, muss der Browser vor der Ausführung des Skripts oder der Anwendung eines durch das <link>-Element angegebenen Stylesheets das Skript oder Stylesheet zuerst mit dem erwarteten Hash abgleichen, der im integrity-Wert angegeben ist.

   Bei der Überprüfung der Subresource-Integrität einer Ressource, die von einem anderen Ursprung als dem Dokument, in dem sie eingebettet ist, bereitgestellt wird, prüfen Browser die Ressource zusätzlich mit Cross-Origin Resource Sharing (CORS), um sicherzustellen, dass der Ursprung, der die Ressource bereitstellt, es erlaubt, sie mit dem anfragenden Ursprung zu teilen.

2. Wenn das Skript oder Stylesheet nicht mit dem zugeordneten integrity-Wert übereinstimmt, muss der Browser die Ausführung des Skripts oder die Anwendung des Stylesheets verweigern und stattdessen einen Netzwerkfehler zurückgeben, der anzeigt, dass das Abrufen dieses Skripts oder Stylesheets fehlgeschlagen ist.

Integritätspolitik

Die Integrity-Policy und Integrity-Policy-Report-Only HTTP-Header ermöglichen es einem Dokument, eine Richtlinie in Bezug auf die Anforderungen an Integritätsmetadaten für geladene Skript- und Stylesheet-Subressourcen durchzusetzen.

Wenn ein Integrity-Policy-Header angegeben wird, blockiert der Browser Anfragen mit no-cors-Modus oder ohne integrity-Attribut und meldet auch Verstöße, wenn ein gültiger Berichterstattung-Endpunkt angegeben ist. Wenn ein Integrity-Policy-Report-Only-Header angegeben wird, erlaubt der Browser Anfragen, die gegen die Richtlinie verstoßen, meldet jedoch Verstöße an den Berichterstattung-Endpunkt (wenn ein gültiger Berichterstattung-Endpunkt angegeben ist).

Entwickler würden typischerweise Integrity-Policy-Report-Only als ersten Einsatzschritt in ihrem Integrity Policy-Prozess verwenden, um sicherzustellen, dass alle Skripte und Stylesheets, die in ihren Dokumenten geladen werden, die entsprechenden Integritätsmetadaten haben. Sobald sie sehen, dass keine Berichtsverletzungen mehr eingehen, wissen sie, dass sie das Blockieren mit dem Integrity-Policy-Header aktivieren können, ohne das Risiko einzugehen, benutzerseitige Brüche zu verursachen.

Die Header-Werte sind als strukturierte Felddictionaires mit den folgenden Schlüsseln definiert:

blocked-destinations

Definiert eine Liste von Anfragezielen, die blockiert werden sollen. Die einzigen erlaubten Werte sind script und style.

sources Optional

Definiert eine Liste von Integritätsquellen. Der Standardwert und derzeit einzige unterstützte Wert ist inline. Somit hat das Hinzufügen von sources=(inline) zum Header eine ähnliche Wirkung wie das Auslassen von sources.

endpoints Optional

Definiert eine Liste von Berichterstattung-Endpunkten. Die Berichterstattung-Endpunkte müssen in einem Reporting-Endpoints-Header definiert werden.

In Fällen, in denen eine Anfrage durch eine Integritätspolitik blockiert wird, wird ein Reporting API-Verletzungsbericht mit einem Typ von integrity-violation und einem Body vom Typ IntegrityViolationReportBody erstellt, der Informationen wie die URL des Dokuments und die blockierte Ressource enthält.

Ein typischer Bericht könnte so aussehen:

{
  "type": "integrity-violation",
  "url": "https://example.com",
  "body": {
    "documentURL": "https://example.com",
    "blockedURL": "https://example.com/main.js",
    "destination": "script",
    "reportOnly": false
  }
}

Beispiele

In den folgenden Beispielen wird angenommen, dass oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC bereits als erwarteter SHA-384-Hash (Digest) eines bestimmten Skripts example-framework.js bekannt ist und es eine Kopie des Skripts unter https://example.com/example-framework.js gibt.

Subresource Integrity mit dem <script>-Element

Sie können das folgende <script>-Element verwenden, um einem Browser mitzuteilen, dass er, bevor er das Skript https://example.com/example-framework.js ausführt, das Skript mit dem erwarteten Hash abgleichen und verifizieren muss, dass eine Übereinstimmung besteht.

<script
  src="https://example.com/example-framework.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>

Durchsetzung der Integrität mit dem Integrity-Policy-Header

Sie können den Integrity-Policy-Header zu Ihrem Dokument hinzufügen, um sicherzustellen, dass die externen Ressourcen, die es lädt (in diesem Fall Skripte), mit Integrität geladen werden (und nicht im no-cors-Modus geladen werden).

Integrity-Policy: blocked-destinations=(script), endpoints=(integrity-endpoint, some-other-integrity-endpoint)

Wenn Sie sich nicht sicher sind, ob alle externen Skripte Integritätsmetadaten aufweisen, können Sie die nur-berichtsbasierte Version der Funktion aktivieren und beginnen, Berichte über Verstöße zu erhalten. Sie können dies mit dem Integrity-Policy-Report-Only-Header tun.

Integrity-Policy-Report-Only: blocked-destinations=(script), endpoints=(integrity-endpoint, some-other-integrity-endpoint)

Spezifikationen

Browser-Kompatibilität

html.elements.link.integrity

html.elements.script.integrity

Siehe auch

• Content Security Policy
• Der Content-Security-Policy HTTP-Header.
• A CDN that can not XSS you: Using Subresource Integrity
• SRI Hash Generator