Subresource Integrity

Websites entscheiden sich manchmal dafür, sich auf eine Drittpartei wie ein Content Delivery Network (CDN) zu verlassen, um einige ihrer Ressourcen zu hosten, anstatt alle Ressourcen selbst zu hosten. Ein Dokument, das beispielsweise von https://example.com bereitgestellt wird, könnte eine Ressource von einem anderen Standort einbinden:

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

Dies birgt das Risiko, dass ein Angreifer, wenn er die Kontrolle über den Drittanbieter-Host erlangt, beliebigen bösartigen Inhalt in seine Dateien injizieren (oder die Dateien vollständig ersetzen) und damit möglicherweise auch Websites angreifen kann, die Dateien davon 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 injiziert hat — und ohne dass jegliche Art von Änderungen an diesen Dateien vorgenommen wurden.

Sie verwenden die Subresource Integrity-Funktion, indem Sie einen Base64-codierten kryptografischen Hash einer Ressource (Datei) angeben, die Sie dem Browser zum Abrufen anweisen, und zwar 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 für einen 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.

SRI Hash Generator

Der SRI Hash Generator ist ein Online-Tool, mit dem Sie SRI-Hashes generieren können.

Verwendung von OpenSSL

Sie können SRI-Hashes von der Befehlszeile aus mit OpenSSL generieren, indem Sie einen Befehl wie folgt ausführen:

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 folgendem 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 in Ihrer Umgebung (z.B. C:\Users\USER\AppData\Roaming\Microsoft\Windows\SendTo).
2. Klicken Sie mit der rechten Maustaste auf eine Datei im Datei-Explorer, wählen Sie Senden an... und wählen Sie dann sri-hash. Sie sehen den Integritätswert in einem Befehlsfenster.
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 generieren, indem Sie einen Befehl wie folgt ausführen:

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

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

Für die Überprüfung der Subresource Integrity einer Ressource, die von einem anderen Ursprung als dem eingebetteten Dokument bereitgestellt wird, überprüfen Browser zusätzlich die Ressource mit Cross-Origin Resource Sharing (CORS), um sicherzustellen, dass der Ursprung, der die Ressource bereitstellt, das Teilen mit dem anfordernden Ursprung erlaubt. Daher muss die Ressource mit einem Access-Control-Allow-Origin-Header bereitgestellt werden, der das Teilen der Ressource mit dem anfordernden Ursprung erlaubt; zum Beispiel:

Access-Control-Allow-Origin: *

Browser behandeln SRI durch folgende Schritte:

1. Wenn ein Browser auf ein <script> oder <link> Element mit einem integrity-Attribut trifft, muss der Browser, bevor er das Skript ausführt oder bevor er ein Stylesheet anwendet, das vom <link>-Element angegeben wird, das Skript oder Stylesheet zunächst mit dem erwarteten Hash im integrity-Wert vergleichen.

   Für die Überprüfung der Subresource Integrity einer Ressource, die von einem anderen Ursprung als dem eingebetteten Dokument bereitgestellt wird, überprüfen Browser zusätzlich die Ressource mit Cross-Origin Resource Sharing (CORS), um sicherzustellen, dass der Ursprung, der die Ressource bereitstellt, das Teilen mit dem anfordernden Ursprung erlaubt.

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

Die Integrity-Policy und Integrity-Policy-Report-Only HTTP-Header ermöglichen es einem Dokument, eine Richtlinie hinsichtlich der Integritätsmetadatenanforderungen an geladene Subressourcen bestimmter Typen (derzeit nur Skripte) durchzusetzen.

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

Entwickler würden typischerweise Integrity-Policy-Report-Only als ersten Schritt in ihrer Integritätspolitik einsetzen, um sicherzustellen, dass alle in ihren Dokumenten geladenen Skripte über geeignete Integritätsmetadaten verfügen. Sobald sie sehen, dass keine Verstöße gemeldet werden, wissen sie, dass sie die Blockierung mit dem Integrity-Policy-Header aktivieren können, ohne das Risiko von Benutzerproblemen einzugehen.

Die Header-Werte sind als strukturierte Feldwörterbücher mit den folgenden Schlüsseln definiert:

blocked-destinations

Definiert eine Liste von Anforderungszielen, die blockiert werden sollen. Der einzige erlaubte Wert ist script.

sources Optional

Definiert eine Liste von Integritätsquellen. Der Standardwert und derzeit einzig unterstützte Wert ist inline. Infolgedessen hat das Hinzufügen von sources=(inline) zum Header einen ähnlichen Effekt wie das Weglassen von sources.

endpoints Optional

Definiert eine Liste von Meldungsendpunkten. Die Meldungsendpunkte müssen in einem Reporting-Endpoints-Header definiert werden.

In Fällen, in denen eine Anforderung durch eine Integritätspolitik blockiert wird, wird ein Verstoßbericht des Reporting API mit dem Typ integrity-violation erstellt und ein Body des Typs IntegrityViolationReportBody erstellt, der Informationen wie die URL des Dokuments und der blockierten 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
  }
}

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 eine Kopie des Skripts unter https://example.com/example-framework.js gehostet wird.

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 zuerst mit dem erwarteten Hash vergleichen und bestätigen muss, dass es übereinstimmt.

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

Sie können den Integrity-Policy-Header zu Ihrem Dokument hinzufügen, um sicherzustellen, dass alle externen Skripte, die es lädt, 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)

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

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

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