Subresource Integrity (SRI) ist ein Sicherheitsmerkmal, das es Browsern ermöglicht zu überprüfen, ob die geladenen Ressourcen (zum Beispiel von einemCDN) ohne unerwartete Manipulation geliefert wurden. Dies funktioniert, indem Sie einen kryptografischen Hash bereitstellen, den eine geladene Ressource erfüllen muss.

Wie Subresource Integrity hilft

Websites entscheiden sich manchmal dafür, auf einen Drittanbieter wie einContent Delivery Network (CDN) zu verzichten, um einige ihrer Ressourcen zu hosten, anstatt alle ihre Ressourcen selbst zu hosten. Zum Beispiel könnte ein vonhttps://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 desintegrity-Attributs eines<script>-Elements oder eines<link>-Elements mitrel="stylesheet",rel="preload" oderrel="modulepreload".

Einintegrity-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äfixesha256,sha384 undsha512), gefolgt von einem Bindestrich und endet mit dem eigentlichen Base64-codierten Hash.

Beispielintegrity-String mit Base64-codiertem sha384-Hash:

sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC

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

Werkzeuge zur Generierung von SRI-Hashes

SRI Hash Generator

DerSRI 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 mitOpenSSL 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 offset bits=384openssl dgst -sha%bits% -binary %1% | openssl base64 -A > tmpset /p a= < tmpdel tmpecho sha%bits%-%a%pause

Um diesen Code zu verwenden:

1. Speichern Sie diesen Code in einer Datei namenssri-hash.bat im Windows-SendTo-Ordner Ihrer Umgebung (zum BeispielC:\Users\USER\AppData\Roaming\Microsoft\Windows\SendTo).
2. Klicken Sie mit der rechten Maustaste auf eine Datei im Explorer, wählen SieSenden an... und dannsri-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 mitshasum mit einem Befehl wie diesem generieren:

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

• Der Pipe-Schrittxxd konvertiert die hexadezimale Ausgabe vonshasum in Binärdaten.
• Der Pipe-Schrittawk ist notwendig, weilshasum den gehashten Dateinamen in seiner Ausgabe anxxd übergibt. Dies kann katastrophale Folgen haben, wenn der Dateiname gültige Hex-Zeichen enthält —xxd würde das dann ebenfalls dekodieren und anbase64 ü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 mitCross-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 einemAccess-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 einemintegrity-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 imintegrity-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 mitCross-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 zugeordnetenintegrity-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

DieIntegrity-Policy undIntegrity-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 einIntegrity-Policy-Header angegeben wird, blockiert der Browser Anfragen mitno-cors-Modus oder ohneintegrity-Attribut und meldet auch Verstöße, wenn ein gültiger Berichterstattung-Endpunkt angegeben ist.Wenn einIntegrity-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 typischerweiseIntegrity-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 demIntegrity-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 vonAnfragezielen, die blockiert werden sollen. Die einzigen erlaubten Werte sindscript undstyle.

sourcesOptional

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

endpointsOptional

Definiert eine Liste vonBerichterstattung-Endpunkten. Die Berichterstattung-Endpunkte müssen in einemReporting-Endpoints-Header definiert werden.

In Fällen, in denen eine Anfrage durch eine Integritätspolitik blockiert wird, wird einReporting API-Verletzungsbericht mit einem Typ vonintegrity-violation und einem Body vom TypIntegrityViolationReportBody 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, dassoqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC bereits als erwarteter SHA-384-Hash (Digest) eines bestimmten Skriptsexample-framework.js bekannt ist und es eine Kopie des Skripts unterhttps://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 Skripthttps://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 demIntegrity-Policy-Header

Sie können denIntegrity-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 imno-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 demIntegrity-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
• DerContent-Security-Policy HTTP-Header.
• A CDN that can not XSS you: Using Subresource Integrity
• SRI Hash Generator