SaaSFort Fragen Sie einen SaaS-Anbieter, wie er erkennen würde, dass ein Drittanbieter-Skript in seiner Anwendung verändert wurde. Die meisten Antworten fallen in drei Gruppen.
“Wir nutzen nur renommierte Anbieter.” Das ist Lieferantenauswahl, nicht Erkennung.
“Wir haben eine CSP.” Eine CSP erlaubt diese Herkunft. Das veränderte Skript kommt genau von dort, wo die Richtlinie Skripte erlaubt.
“Wir prüfen unsere Abhängigkeiten.” Das deckt ab, was Sie bauen, nicht was ein CDN ausliefert.
Die ehrliche Antwort lautet für die meisten Anbieter: Sie wüssten es nicht.
Warum dieser Angriff alle üblichen Kontrollen passiert
Gehen wir durch, was geschieht, wenn ein CDN, das Ihr Analytics- oder Support-Widget ausliefert, kompromittiert wird und verändertes JavaScript ausliefert.
| Kontrolle | Zustand während des Angriffs |
|---|---|
| TLS | Gültig. Die Verbindung ist korrekt verschlüsselt. |
CSP script-src | Besteht. Die Herkunft steht auf der Positivliste. |
| Authentifizierung | Unberührt. Die Nutzerin ist regulär angemeldet. |
| WAF | Sieht nichts. Die Anfrage geht vom Browser zum CDN, ohne Ihre Infrastruktur zu berühren. |
| Abhängigkeitsscan | Sieht nichts. Das steht zur Buildzeit nicht in Ihrer package.json. |
| Pentest vom letzten Quartal | Hat das Skript geprüft, das im Juni dort lag. |
Das Skript läuft in Ihrer Herkunft, mit Zugriff auf Ihr DOM, Ihre Formulare und jedes aus JavaScript erreichbare Token. Das ist ein glaubwürdiger Weg zu massenhaftem Zugangsdatendiebstahl, und er wurde wiederholt so genutzt.
Der Grund, warum er allem entgeht, ist strukturell: Jede Kontrolle oben prüft Herkunft oder Transport, und keine prüft Inhalt.
Die Kontrolle, die den Inhalt prüft
Subresource Integrity. Sie veröffentlichen den Hash der Datei, die Sie freigegeben haben, der Browser berechnet den Hash des Empfangenen, und bei Abweichung wird das Skript nicht ausgeführt.
<script src="https://cdn.example.com/widget.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>
Das funktioniert, mit einem Mangel ohne Bezug zur Kryptografie: Es ist freiwillig, Tag für Tag. Das Skript, das jemand im nächsten Quartal ohne integrity-Attribut ergänzt, ist ungeschützt, und teilweise SRI-Abdeckung schützt nicht, denn dem Angreifer genügt ein einziges ungeschütztes Skript.
Die Abdeckung zerfällt standardmäßig. Das ist kein Disziplinproblem, sondern das, was jedem Kontrollmechanismus widerfährt, dessen Wirksamkeit davon abhängt, dass sich alle für immer daran erinnern.
Den Mechanismus strukturell machen
Integrity-Policy verschiebt die Anforderung vom Tag auf die Seite. Der Browser blockiert dann jedes Skript ohne Integritätsmetadaten, auch das im nächsten Quartal ergänzte.
Integrity-Policy: blocked-destinations=(script), endpoints=(integrity-endpoint)
Reporting-Endpoints: integrity-endpoint="https://example.com/_reports/integrity"
Die einzuplanende Falle: Es gibt keine Ausnahme für Erstanbieter. Auch Ihre eigenen Bundles brauchen Integritätsmetadaten, was eine Änderung der Build-Pipeline ist und keine Header-Änderung. Rollen Sie zuerst Integrity-Policy-Report-Only aus, nutzen Sie die entstehende Verstoßliste als Inventar, und erzwingen Sie, sobald sie leer ist.
Der vollständige Rollout-Weg und die Browserunterstützung.
Die Frage im Fragebogen beantworten
Der Abstand zwischen schwacher und starker Antwort ist hier ungewöhnlich groß, weil die meisten Wettbewerber die schwache geben.
Schwach: “Wir nutzen renommierte Drittanbieter und prüfen sie jährlich.”
Stark:
Drittanbieter-Skripte werden über zur Buildzeit erzeugte Subresource-Integrity-Hashes gepinnt.
Integrity-Policywird im Browser durchgesetzt, sodass jedes ohne Integritätsmetadaten ausgelieferte Skript blockiert statt still ausgeführt wird, auch neu hinzugefügte. Verstöße gehen an einen internen Endpunkt, der alarmiert. Unsere CSP nutzt Nonce plusstrict-dynamicstatt einer Herkunfts-Positivliste, sodass einer kompromittierten erlaubten Herkunft nicht automatisch vertraut wird.
Vier getrennte Mechanismen, jeder überprüfbar, und sie beantworten unmittelbar die Erkennungsfrage statt der Auswahlfrage.
Die Pflicht hinter der Frage
Das ist nicht nur eine Frage guter Praxis. Lieferkettensicherheit ist eine ausdrückliche Pflicht:
- NIS2 Artikel 21(2)(d), Sicherheit der Lieferkette, einschließlich sicherheitsbezogener Aspekte der Beziehungen zu direkten Lieferanten. Wo die meisten Anbieter eine Lücke haben.
- NIS2 Artikel 21(2)(g), Cyberhygiene.
- ISO/IEC 27001:2022 A.5.21, Management der Informationssicherheit in der IKT-Lieferkette, und A.8.28, sichere Entwicklung.
- DORA Artikel 28, IKT-Drittparteienrisiko, wo die Anforderung ebenso vertraglich wie technisch ist.
Die regulatorische Rahmung hat sich von “wählen Sie gute Lieferanten” hin zu “weisen Sie nach, dass Sie das Versagen eines Lieferanten erkennen würden” verschoben. SRI-Durchsetzung ist einer der ganz wenigen Kontrollmechanismen, der die zweite Formulierung mit einem technischen Mittel beantwortet statt mit einem Prozessdokument.
Verhältnis zu einer SBOM
Eine SBOM sagt, wovon Sie abhängen. Integritätsdurchsetzung sagt, dass ausgeliefert wurde, was Sie freigegeben haben. Beides ergänzt sich und wird häufig verwechselt.
Eine SBOM hätte ein kompromittiertes CDN nicht erkannt, denn die Abhängigkeitsliste war durchgehend korrekt. Verändert hat sich die Datei unter dieser URL.
Kurzfassung
Ein kompromittiertes Drittanbieter-Skript passiert TLS, CSP, Authentifizierung, Ihre WAF und Ihren Abhängigkeitsscanner, weil all diese prüfen, woher Code kommt, und keiner prüft, was er enthält.
SRI prüft den Inhalt. Integrity-Policy macht SRI unvergesslich. Zusammen sind sie die einzige Antwort auf “woher wüssten Sie es”, die ein Mechanismus ist und keine Hoffnung.
Von der Theorie zur Praxis
Scannen Sie Ihre Domain kostenlos. Erste Ergebnisse in unter 10 Sekunden — ohne Registrierung.