Entwicklertools · SHA-Hash-Rechner
Subressourcenintegrität: Wie Browser SHA-384 verwenden, um Skripte zu überprüfen
· Hintergrund
sha-256 base64 Browser-APIs Sicherheit
Mit dem Integritätsattribut kann ein Browser ein CDN-Skript ablehnen, dessen Bytes sich geändert haben. In diesem Beitrag wird das Format des Attributs erläutert, warum SHA-384 in Base64 die häufigste Wahl ist und wovor SRI keinen Schutz bieten kann.
Das CDN, das alles bedienen kann – das Lieferkettenrisiko, für das SRI entwickelt wurde
Ein Skript-Tag auf einer Webseite kann ein Integritätsattribut tragen: `<script src="https://cdn.example.com/lib.js" integrity="sha384-..."></script>`. Der Integritätswert ist ein kryptografischer Auszug der Bytes des Skripts. Wenn der Browser das Skript herunterlädt, berechnet er den Digest der empfangenen Bytes und vergleicht ihn mit dem Integritätsattribut. Wenn sie übereinstimmen, wird das Skript geladen. Wenn sie nicht übereinstimmen, verweigert der Browser das Laden und meldet den Fehler in der Konsole. Dies schützt vor einem kompromittierten CDN, das geänderten Code bereitstellt, oder davor, dass ein Netzwerkangreifer die Antwort abfängt und verändert.
Subresource Integrity (SRI) ist eine W3C-Spezifikation, die für Skripte und Stylesheets gilt. Dies ist die einzige kryptografische Garantie, die ein Browser über den Inhalt einer Cross-Origin-Ressource geben kann: Die Bytes müssen mit dem Digest übereinstimmen, sonst wird die Ressource abgelehnt. Dies beweist nicht, wer die Ressource erstellt hat, sondern nur, dass sie sich seit der Berechnung des Digests nicht geändert hat. Für eine Ressource, die über HTTPS von einem seriösen CDN bereitgestellt wird, bietet der Digest einen Schutz davor, dass das CDN kompromittiert wird oder Ihnen speziell veraltete zwischengespeicherte Inhalte bereitgestellt werden.
Das Integritätsattribut – Algorithmuspräfix, Bindestrich, Base64-Digest und Unterstützung für mehrere Hashes
Das Integritätsattribut hat ein bestimmtes Format: Algorithmusname, Bindestrich, Digest in Base64. Beispiel: `integrity="sha384-JZDdQnrrAMe+sxxpn47in+PwhkxrCrt4SNvt+xWqV3zPJUkeFF0Qq/wNtuvNqPP5"`. Der Algorithmusname kann SHA-256, SHA-384 oder SHA-512 sein. Base64 ist die Kodierung, nicht hexadezimal; Dies ist eine bewusste Entscheidung der SRI-Spezifikation. Base64 ist kompakter als Hex (ca. 33 % kürzer für denselben Digest), was beim Einbetten in HTML-Attribute wichtig ist. Der Bindestrich trennt den Algorithmusnamen vom Digest. Es können mehrere Integritätswerte durch Leerzeichen getrennt aufgelistet werden: Wenn einer von ihnen übereinstimmt, wird die Ressource akzeptiert.
Warum SHA-384? Die SRI-Spezifikation erlaubt SHA-256, SHA-384 und SHA-512. SHA-384 wurde zum Community-Standard, da es ein Größenguthaben von /security bietet. SHA-256 ist kleiner (32 Bytes, 44 Zeichen in Base64), aber SHA-384 ist breiter (48 Bytes, 64 Zeichen in Base64) und hat die Attributgröße im Vergleich zu SHA-256 nicht wesentlich erhöht. SHA-512 ist verfügbar, wird aber selten verwendet, da sein größerer Digest für diesen Anwendungsfall nicht notwendig schien. Die Wahl von SHA-384 ist historisch und pragmatisch und kein Ausdruck überlegener Sicherheitseigenschaften (alle drei sind für diesen Zweck kryptografisch stark).
SHA-384 wird angeboten und produziert das benötigte Base64-Material; Community-Präferenzen werden nicht aus dem Tool abgeleitet
Die Base64-Codierung in SRI ist Standard-Base64, nicht Base64url. Standard-Base64 verwendet die Zeichen + und /, die in HTML-Attributen ohne Prozentkodierung gültig sind, obwohl sie in URLs und Formulardaten eine besondere Bedeutung haben. Das SRI-Format ist für HTML-Attribute und nicht für URLs konzipiert, daher ist Standard-Base64 geeignet. Wenn Sie einen Integritätswert manuell erstellen, berechnen Sie den SHA-384-Digest (eine Folge von Bytes), codieren diese Bytes dann als Standard-Base64, stellen dann `sha384-` voran und fügen es in das Integritätsattribut ein.
Der Browser führt die gleichen Schritte in umgekehrter Reihenfolge aus: Base64 aus dem Integritätsattribut extrahieren, in Bytes dekodieren, um den Digest wiederherzustellen, SHA-384 der heruntergeladenen Skriptbytes berechnen und die beiden Digest-Werte vergleichen. Sie müssen genau übereinstimmen; Ein einzelner Bit-Unterschied im Digest führt zur Ablehnung. Es gibt kein Fuzzy-Matching oder Teilgutschrift: Integrität ist binär.
Das Cross-Origin-SRI-Verhalten erfordert eine Browserdokumentation, die über diesen Hash-Rechner hinausgeht
SRI erfordert CORS für Cross-Origin-Antworten. Wenn Sie ein Skript von einem anderen Ursprung laden, muss der Server mit `Access-Control-Allow-Origin: *` oder einem bestimmten Ursprungsheader antworten, der Ihren enthält. Ohne CORS-Header kann der Browser den SRI nicht überprüfen, da er ohne CORS nicht bestätigen kann, dass der Antworttext mit dem übereinstimmt, was der Server senden wollte. CORS-Header sind die Aussage des Servers, dass diese Antwort sicher überprüft werden kann; Mit SRI überprüfen Sie, ob die Bytes korrekt sind. Zusammen bilden sie eine Lieferkettenverpflichtung: Der Server ermöglicht es Ihnen, den Inhalt zu überprüfen, und das tun Sie auch.
Wenn einem Cross-Origin-Skript CORS-Header fehlen und es über ein Integritätsattribut verfügt, lädt der Browser es herunter (sofern Skripte von diesem Ursprung vom CSP der Site zugelassen werden), die Integrität wird jedoch nicht überprüft. Das Skript wird geladen, als ob das Integritätsattribut fehlen würde. Dies ist kein Versagen von SRI; Es handelt sich um eine Sicherheitsgrenze: Sie können eine Antwort, die Sie nicht lesen können, nicht überprüfen.
Was passiert bei Nichtübereinstimmung – der Browser blockiert die Ressource und meldet dies in der Konsole
Wenn der Browser einen Integritätskonflikt erkennt, verweigert er die Ausführung des Skripts und protokolliert eine Meldung in der Browserkonsole. Die Nachricht nennt typischerweise die URL, den erwarteten Hash und den berechneten Hash. Der Fehler ist atomarer Natur: Entweder wird die Ressource unverändert geladen oder sie wird vollständig abgelehnt. Es gibt kein Teilladen oder Fallback. Wenn sich eine Website auf dieses Skript verlässt und es abgelehnt wird, kann es sein, dass die Website nicht funktioniert. Dies ist beabsichtigt: Die Bereitstellung von falschem Code ist schlimmer als die Bereitstellung von keinem Code, und stille Fehler ermöglichen, dass Angriffe auf unbestimmte Zeit andauern.
Das Testen eines SRI-Setups ist unkompliziert: Öffnen Sie die Browserkonsole, laden Sie die Seite und suchen Sie nach Meldungen über Integritätskonflikte. Wenn Sie eine Nichtübereinstimmung feststellen, vergleichen Sie den in der Konsole angezeigten berechneten Hash mit dem in Ihrem Integritätsattribut. Wenn sie nicht übereinstimmen, führen Sie eine Neuberechnung durch: Möglicherweise wurde das Skript aktualisiert und Sie benötigen einen neuen Digest.
Bearbeitetes Beispiel – Berechnen eines Digests für ein Skript und Formatieren in einen Integritätswert, einschließlich des Base64-Schritts
Für die manuelle Berechnung eines SRI-Digests sind nur die Skriptbytes und ein Hash-Tool erforderlich. Laden Sie das Skript herunter, fügen Sie es in den ToolAcre SHA-Hash-Rechner ein, wählen Sie SHA-384 aus, kopieren Sie die Base64-Ausgabe (nicht das Hex), stellen Sie `sha384-` voran und fügen Sie es in das Integritätsattribut ein. Wenn das Skript umfangreich ist, ist es schneller, es mit Curl oder Wget in einer Datei zu speichern und die Datei dann zu lesen, als es einzufügen. Für Inline-Skripte (in einem `<script>`-Tag im HTML statt von einer URL) ist SRI nicht anwendbar; Inline-Skripte sind per Definition immer vertrauenswürdig. SRI ist für externe Ressourcen.
Ein funktionierendes Beispiel: Angenommen, Sie möchten jQuery von einem CDN mit SRI laden. Suchen Sie die Skript-URL, laden Sie sie herunter (oder rufen Sie sie mit Curl ab), fügen Sie die Bytes in den Rechner ein oder verwenden Sie `sha384sum` in der Befehlszeile, rufen Sie den SHA-384-Digest als Base64 ab und formatieren Sie ihn als `sha384-[base64-digest]`. In das Integritätsattribut des Skript-Tags einfügen. Laden Sie die Seite und stellen Sie sicher, dass keine Konsolenfehler angezeigt werden.
Was dies nicht abdeckt – Skripte, die sich absichtlich ändern, und Websites wie ToolAcre, die überhaupt keine externen Skripte laden und daher nichts anzupinnen haben
SRI schützt nicht vor allen Angriffen auf die Lieferkette. Es schützt vor Byteänderungen, nachdem der Digest berechnet wurde, aber nicht davor, dass der Digest von vornherein aus kompromittiertem Code berechnet wird. Wenn ein CDN kompromittiert wird, bevor Sie den Digest berechnen, kann SRI nicht helfen. Der Digest ist nur so vertrauenswürdig wie die Quelle, aus der Sie ihn berechnet haben. Für maximale Sicherheit berechnen Sie Digests aus der Originalquelle (z. B. den GitHub-Releases der Bibliothek) und verwenden Sie diese Digests beim Laden von einem CDN. Der Digest wird durch den Release-Prozess zu einer Verpflichtung des Betreuers.
SRI bietet auch keinen Schutz vor einem kompromittierten Netzwerk zum Zeitpunkt der Berechnung des Digests oder vor einem kompromittierten Entwicklungscomputer. Es schützt nur vor Änderungen am Skript zwischen der Erstellung des Digests und dem Zeitpunkt, an dem der Browser das Skript lädt. Zur fortlaufenden Sicherheit verwenden einige Bereitstellungen zusätzlich zu SRI die Release-Signierung: Die Version wird mit dem Schlüssel eines Betreuers signiert, Sie überprüfen die Signatur, berechnen den Digest aus den überprüften Bytes und verwenden ihn in SRI.
In diesem Artikel wird nicht der standortweite externe Skriptbestand von ToolAcre aus Hash-Quellen bestätigt
Der ToolAcre SHA-Hash-Rechner gibt den Digest im Standard-Base64 direkt aus (als `base64`-Ausgabe der Funktion `toBase64()`). Um in das SRI-Format zu konvertieren, stellen Sie dem Algorithmusnamen und einem Bindestrich voran: `sha256-`, `sha384-` oder `sha512-`. Der Rechner wendet dieses Präfix nicht automatisch an, da Hashes in vielen Kontexten (git, Docker, npm, URLs) vorkommen, in denen der Algorithmusname separat oder anders codiert ist. Die Grenze ist klar: Der Rechner hasht UTF-8 Text, den Sie einfügen, nicht Dateien oder Binärschlüssel. Es gibt sowohl Hex als auch Base64 aus. Sie wählen basierend auf Ihrem Kontext aus, welche Sie verwenden möchten. Für SRI ist laut Spezifikation base64 erforderlich. Für Git und andere Tools ist Hex konventionell. Für npm und Go wird base64 verwendet. Die Wahl der Kodierung liegt bei Ihnen; Die Digest-Bytes sind gleich.
SRI bleibt eine der wenigen kryptografischen Prüfungen, die ein Browser clientseitig ohne eine zentrale Autorität durchführen kann. Die Berechnung von Digests mit einem vertrauenswürdigen Tool wie dem SHA-Rechner von ToolAcre und deren Überprüfung anhand geladener Ressourcen ist eine einfache Möglichkeit, eine Website gegen bestimmte Angriffe auf die Lieferkette abzusichern. Der Schutz ist nur so gut wie die Verdauung; Führen Sie nach jeder Aktualisierung der externen Ressource eine Neuberechnung durch und testen Sie, ob der Browser das Skript lädt, ohne es abzulehnen.