Zusammenfassung

  • Der erste öffentliche Entwurf von Subresource Integrity erschien am 18. März 2014. Er schlug vor, geladene Ressourcen mit kryptografischen Hashwerten abzugleichen, und betrachtete mehr HTML-Elemente als die spätere Empfehlung.
  • Die W3C-Empfehlung vom 23. Juni 2016 legte integrity für Skripte und Stylesheet-Links fest. Der Browser vergleicht eine prüfbare Antwort mit dem erwarteten Hash und verweigert bei Abweichung Ausführung oder Darstellung.

Der Kurier fand die richtige Adresse und kam pünktlich. Das Skript war hier Stammgast. Doch niemand wusste allein vom Straßenschild, was diesmal im Paket lag. Verändertes JavaScript kann das Verhalten der Seite ändern; ein anderes Stylesheet kann ihr Gesicht neu zeichnen. Die URL sagt, wo der Browser abholen soll. Der Hash sagt, welche Fassung die Seite bestellt hat.

Der erste öffentliche W3C-Arbeitsentwurf vom 18. März 2014 stellte den Vergleich einer geladenen Ressource mit einem kryptografischen Hash in den Mittelpunkt. Damals stand eine breite Auswahl an Elementen auf dem Prüfstand, von Skripten und Stylesheets bis zu Bildern und Frames. Auf dem Zeichentisch war Platz für vieles. Die spätere Empfehlung konzentrierte den Mechanismus auf einen engeren Einsatz.

Im Candidate Recommendation Snapshot vom 12. November 2015 bezog sich das integrity-Attribut auf script und auf link für Stylesheets. Die W3C-Empfehlung vom 23. Juni 2016 behielt diese beiden Eintrittspunkte bei. Der Autor schreibt die Hash-Metadaten neben die Ressourcen-URL in HTML. Der Browser lädt die Ressource, berechnet den Hash einer prüfbaren Antwort und vergleicht ihn mit dem erwarteten Wert. Erst die Ware, dann der Einlass.

Zu den Metadaten gehören die Hashfunktion und der erwartete Wert. Die Empfehlung verpflichtete Benutzerprogramme zur Unterstützung von SHA-256, SHA-384 und SHA-512. Für eine Ressource dürfen mehrere Werte angegeben werden; die stärkste unterstützte Hashfunktion erhält Vorrang. Genau dort, wo eine fremde Datei ausführbarer Code oder sichtbares Layout wird, kann die Seite eine konkrete erwartete Fassung benennen.

Auch die Antwort selbst muss sich prüfen lassen. Eine Antwort gleicher Herkunft ist geeignet, eine Antwort anderer Herkunft ebenfalls, wenn CORS den Zugriff darauf eröffnet. Eine undurchsichtige Antwort liefert dem Browser die nötigen Bytes für den Vergleich nicht. Der Herausgeber musste somit einen passenden Hash und einen überprüfbaren Lieferweg zusammenbringen. Die Kontrolle hängt an den wirklichen Regeln des Abrufs.

Passen die Werte nicht zusammen, verlangt die Empfehlung von 2016, dass der Browser Ausführung oder Darstellung verweigert und einen Netzwerkfehler meldet. Ein Fehlerereignis erlaubt dem Autor, eine bekannte Ersatzdatei bereitzustellen. Selbst der Stammkurier muss mit der falschen Schachtel vor der Tür warten. Wie der Leser seine Aufgabe fortsetzen kann, entscheidet danach das Seitenteam.

Die W3C-Veröffentlichungsgeschichte verbindet den ersten Entwurf von 2014 mit der Kandidatenstufe 2015 und der Empfehlung 2016. Die Ankündigung vom 23. Juni 2016 beschrieb das Ziel als Prüfung auf unerwartete Änderungen an einer geladenen Ressource. Der Weg durch die Dokumente zeigt zugleich die Verengung der frühen Elementliste auf Skripte und Stylesheet-Links.

Für den Herausgeber folgt daraus eine alltägliche Pflicht. Ändert er die Datei absichtlich, muss er den erwarteten Hash mit ändern. Ein alter Hash stoppt auch die gewollte neue Fassung. Der Autor bestimmt die Bestellung, der Browser vergleicht die Lieferung. Die URL führt den Kurier zum Haus. Der Fingerabdruck sagt, ob er das richtige Paket trägt.