Ein Skript vom CDN zu laden funktioniert wie ein Paket mit angeklebtem Siegel. Niemand prüft, ob der Inhalt noch dem Siegel entspricht – man reißt einfach auf und legt los.
Das Paket wird von einem fremden Lagerhaus verschickt, dem CDN, und landet ungeprüft im eigenen Regal. Der Umtauschzettel sagt nur, woher das Paket kommt. Steht aber drin, was drin sein muss, fehlt jede Kontrolle. Wer den Umtauschzettel um ein Detail ergänzt, erkennt jede Manipulation sofort.
Der Umtauschzettel heißt integrity-Attribut, der Zettelinhalt ist ein Hash, ein Prüfwert, der aus genau der gewünschten Datei berechnet wurde. Der Browser bildet beim Empfang denselben Hash und vergleicht ihn mit dem Attribut. Die Herkunft nennt das src-Attribut mit der CDN-Adresse, das Siegel ist der Base64-kodierte Prüfwert hinter sha256 oder sha384.
Konkret sieht das so aus: Das script-Tag bekommt src mit der CDN-Adresse der Bibliothek, integrity mit dem sha384-Hash der Datei und zusätzlich das Attribut crossorigin. Ändert das CDN die Datei auch nur um ein Byte, verweigert der Browser die Ausführung und meldet den Fehler in der Konsole. Die Seite läuft weiter, verliert aber Funktionen des blockierten Skripts.
Das Bild hat eine Grenze: Ein Paketsiegel prüft niemand, der selbst umtauscht. Genau das passiert bei jedem Bibliotheks-Update: Der neue Hash muss berechnet und im Attribut ersetzt werden, sonst blockiert der Browser die eigene neue Version. Auch HTTPS hilft hier nicht; Verschlüsselung schützt nur den Transportweg, nicht den Inhalt auf dem fremden Server.
Cross-Site Scripting, also eingeschmuggelter Code im Opfer-Browser, beginnt nicht erst im eigenen Markup. Schon das ungeprüfte CDN-Skript ist eine XSS-Schleuse. Subresource Integrity heißt: dem fremden Server vertrauen, aber prüfen.
📌 integrity-Attribut · Hash-Vergleich · CDN-Skript
📚 Webentwicklung von Grund auf · Tag 22 von 30
#WebSecurity #webdev #javascript #frontend
Das Paket wird von einem fremden Lagerhaus verschickt, dem CDN, und landet ungeprüft im eigenen Regal. Der Umtauschzettel sagt nur, woher das Paket kommt. Steht aber drin, was drin sein muss, fehlt jede Kontrolle. Wer den Umtauschzettel um ein Detail ergänzt, erkennt jede Manipulation sofort.
Der Umtauschzettel heißt integrity-Attribut, der Zettelinhalt ist ein Hash, ein Prüfwert, der aus genau der gewünschten Datei berechnet wurde. Der Browser bildet beim Empfang denselben Hash und vergleicht ihn mit dem Attribut. Die Herkunft nennt das src-Attribut mit der CDN-Adresse, das Siegel ist der Base64-kodierte Prüfwert hinter sha256 oder sha384.
Konkret sieht das so aus: Das script-Tag bekommt src mit der CDN-Adresse der Bibliothek, integrity mit dem sha384-Hash der Datei und zusätzlich das Attribut crossorigin. Ändert das CDN die Datei auch nur um ein Byte, verweigert der Browser die Ausführung und meldet den Fehler in der Konsole. Die Seite läuft weiter, verliert aber Funktionen des blockierten Skripts.
Das Bild hat eine Grenze: Ein Paketsiegel prüft niemand, der selbst umtauscht. Genau das passiert bei jedem Bibliotheks-Update: Der neue Hash muss berechnet und im Attribut ersetzt werden, sonst blockiert der Browser die eigene neue Version. Auch HTTPS hilft hier nicht; Verschlüsselung schützt nur den Transportweg, nicht den Inhalt auf dem fremden Server.
Cross-Site Scripting, also eingeschmuggelter Code im Opfer-Browser, beginnt nicht erst im eigenen Markup. Schon das ungeprüfte CDN-Skript ist eine XSS-Schleuse. Subresource Integrity heißt: dem fremden Server vertrauen, aber prüfen.
📌 integrity-Attribut · Hash-Vergleich · CDN-Skript
📚 Webentwicklung von Grund auf · Tag 22 von 30
#WebSecurity #webdev #javascript #frontend
13 Std vor
