Drittanbieter-Skripte werden weiterhin von einer aufgegebenen CDN-Domain geladen

Tausende von Websites laden immer noch Drittanbieter-Skripte von einer Content-Delivery-Network-Domain, die jemand im Juli 2025 neu registriert hat, Jahre nachdem der dahinterstehende Dienst eingestellt wurde. Die Domain war abgelaufen, aber ihre Aufrufer verschwanden nicht: Ein von Report URI verfasster Artikel, der von The Hacker News veröffentlicht wurde, berichtet, dass Tausende von Websites, Code-Repositories und Dokumentationsseiten immer noch fest codierte Verweise auf Hostnamen darunter enthalten. Der neue Besitzer hat Wildcard-DNS für die gesamte Domain, was bedeutet, dass jeder Hostname darunter jetzt auf eine Infrastruktur auflöst, die diese Person kontrolliert. Der Apex, die Hauptadresse der Domain, zeigt derzeit eine werbelastige Medien-Downloader-Seite, was für sich genommen nichts Ungewöhnliches ist. Was zählt, ist, dass die Entscheidung darüber, was diese Tausenden von Seiten als Nächstes laden, jetzt bei einem Fremden liegt, und niemand wurde benachrichtigt, weil von außen betrachtet nichts kaputt ging.

Dieses Muster ist nicht hypothetisch. Im Juni 2024 wechselte die Domain polyfill.io, ein JavaScript-Shim, der in mehr als 110.000 Websites eingebettet war, den Besitzer und begann, bedingte Weiterleitungen an Besucher auf Mobilgeräten auszuliefern. Die Websites, die es ausführten, waren nicht gehackt worden; sie hatten vor Jahren einen Script-Tag ausgelagert und die Entscheidung nie überprüft. Ein Script-Tag ist eine Codezeile, die einen Browser anweist, eine Datei abzurufen und auszuführen, die woanders gehostet wird, und ein Shim ist ein kleines Stück Code, das Lücken in älteren Browsern schließt. Beide Fälle teilen ein Problem, das die meisten Sicherheitsteams nicht kontrollieren können: Der bösartige Code war nie auf ihrem Server, und er kam lange nach dem letzten Deployment.

Serverseitige Tools suchen am falschen Ort, argumentiert der Artikel. Statische Analyse, Dependency-Scanning und Software-Composition-Analyse untersuchen alle, was eine Organisation baut und ausliefert, aber ein Drittanbieter-Skript ist nichts davon. Es wird vom Browser des Besuchers abgerufen, von einem Server, den die Organisation nicht betreibt und nicht kontrollieren kann, live bei jedem Seitenaufruf. Das macht es einzigartig feindselig gegenüber konventionellen Tests, weil die Antwort je nach Geografie, User-Agent, Referrer, Tageszeit und Sitzung variieren kann. Ein Crawler, der die Datei einmal aus einem Rechenzentrums-Adressbereich abruft, kann eine saubere Version erhalten, während ein Käufer in einem Mobilfunknetz in einem anderen Land etwas Bösartigeres bekommt. Das Drittanbieter-Skript selbst hat dieselben Privilegien wie First-Party-Code: Es kann das DOM (die Seitenstruktur, die ein Browser aufbaut) lesen, Formularfelder Zeichen für Zeichen beim Tippen lesen, Cookies und lokalen Speicher lesen und ausgehende Anfragen an beliebige Ziele stellen. Clientseitige Angriffe vom Magecart-Typ erfordern überhaupt keinen Server-Einbruch; sie erfordern, dass ein genehmigtes Script-Tag beginnt, sich anders zu verhalten.

Es gibt einen zuverlässig anwesenden Beobachter für jeden dieser Seitenaufrufe: den Browser, der den Code ausgeführt hat. Content Security Policy (CSP), eine Reihe von Anweisungen, die eine Website an Browser sendet und auflistet, welche Codequellen ausgeführt werden dürfen, wird normalerweise als Verteidigung gegen Cross-Site-Scripting diskutiert, und das ist sie auch. Ihre zweite Funktion ist nützlicher für ein Sicherheitsteam, das noch nicht weiß, welchen Code es ausführt: Eine Richtlinie kann steuern, welcher Code ausgeführt werden darf, Code blockieren, der nicht autorisiert ist, und melden, wenn dies geschieht. Diese Berichte kommen aus echten Sitzungen, an echten Orten, von echten Nutzern auf ihren echten Geräten, sodass eine bösartige Nutzlast, die nur für angemeldete Nutzer in einem Land ausgelöst wird, dennoch gemeldet wird, weil der Browser, der sie ausgeführt hat, die Warnung sendet. Der Artikel nennt ein konkretes Beispiel: Im September 2026 deckten von Report URI gesammelte Warnungen eine Gruppe kompromittierter E-Commerce-Websites auf, die eine Social-Engineering-Kampagne der 'ClickFix'-Familie ausführten. Base64-kodierte Loader, also als gewöhnlicher Text getarnter Code, waren nach einer administrativen Kompromittierung in CMS-Inhalte eingepflanzt worden und verketteten sich über einen Redirector zu einem gefälschten 'verify you are human'-Overlay, das einen PowerShell-Befehl in die Zwischenablage des Opfers legte und ihn als geplante Aufgabe persistierte. Die vom Angreifer kontrollierten Hostnamen tauchten in Warnungen aus den Browsern der Opfer auf, während mehrere dieser Domains noch von gängigen Reputationsdiensten als sauber eingestuft wurden. Kein Scanner hatte die Seiten markiert, weil sie auf dem Server in Ordnung waren.

Der häufige Einwand ist, dass eine Content Security Policy die Website kaputt macht, aber im Report-Only-Modus kann sie das nicht. Content-Security-Policy-Report-Only erzwingt nichts, blockiert nichts und ändert kein Verhalten; sie meldet nur, was eine Richtlinie blockiert hätte. Das macht das erste Deployment zu einer sicheren Messübung und sammelt alle Daten, die benötigt werden, um zu wissen, welcher Code auf einer Website läuft. Für die meisten Organisationen ist diese Liste viel länger als erwartet, sagt der Artikel.

Für alle, die Kartenzahlungen abwickeln, ist die Sache bereits entschieden. Die Anforderungen 6.4.3 und 11.6.1 von PCI DSS Version 4.0.1 sind am 31. März 2025 von Best Practice zu verpflichtend geworden. Zusammen verlangen sie, dass jedes Skript auf einer Zahlungsseite autorisiert ist, dass seine Integrität sichergestellt ist, dass ein schriftliches Inventar mit geschäftlicher Begründung existiert und dass ein Mechanismus unbefugte Änderungen an Zahlungsseiteninhalten und HTTP-Headern (die Hintergrundinformationen, die ein Webserver mit jeder Seite sendet) erkennt und meldet. Ein QSA, ein qualifizierter Sicherheitsprüfer, der die Kartenzahlungskonformität prüft, kann und wird nach dem Inventar, dem Melde mechanismus und dem Nachweis fragen, den er erzeugt hat. Report URI gibt an, dass sein Produkt alle drei liefern kann.

Der Artikel beschreibt ein dreistufiges Deployment: eine Woche lang erste Daten sammeln, aus dem Gemeldeten ein Inventar erstellen, dann Änderungen im Laufe der Zeit überwachen und genehmigen oder ablehnen. Er zitiert auch einen zehnjährigen täglichen Crawl der Top-1-Million-Websites, der zeigt, dass die CSP-Akzeptanz im Laufe des Jahrzehnts um mehr als 12.000 % gewachsen ist; der Artikel nennt nicht, wer diesen Crawl durchgeführt hat. Dieses Wachstum, so argumentiert er, spiegelt einen breiteren Wandel wider, wo Organisationen Sichtbarkeit benötigen: nicht nur darüber, was sie bereitstellen, sondern darüber, welchen Code die Browser ihrer Nutzer tatsächlich ausführen.

Report URI beschreibt sich in dem Artikel als eine clientseitige Sicherheitsplattform, die Fragen beantwortet, die ein Sicherheitsteam sonst nicht über seine eigene Website beantworten kann: welche Dritten Code auf seinen Seiten ausführen, welche sich seit gestern geändert haben und welche Daten abgreifen oder mit bekanntermaßen feindseliger Infrastruktur kommunizieren. Die an echte Nutzer ausgelieferten Skripte werden gehasht und archiviert, damit Änderungen nachträglich identifiziert und untersucht werden können, Hostnamen werden gegen Threat Intelligence geprüft und Richtlinien auf Abweichungen überwacht, wodurch die Lücke zwischen dem Genehmigten und dem tatsächlich Laufenden geschlossen wird. Das Deployment fügt der Seite kein JavaScript und dem Stack keinen Agenten, kein Modul und kein SDK hinzu; der erste Schritt besteht darin, einen HTTP-Response-Header hinzuzufügen und zu lesen, was in den folgenden 48 Stunden zurückkommt. Leser sollten die Empfehlungen abwägen im Wissen, dass der Artikel ein von Report URI verfasster Beitrag ist, dem Anbieter der beschriebenen Plattform, und dass er mit einem Angebot für eine 30-tägige kostenlose Testversion endet, die keine Kreditkarte und keine Codeänderungen an der Website erfordert.

Die praktische Lehre für Website-Betreiber ist, dass ein Script-Tag eine langlebige Entscheidung ist. Jeder Verweis auf einen externen Hostnamen ist eine Abhängigkeit von demjenigen, der diesen Hostnamen heute besitzt, nicht von demjenigen, der ihn besaß, als der Code hinzugefügt wurde, und das sind nicht immer dieselben Unternehmen. Ein Inventar, eine Report-Only-Richtlinie und die Gewohnheit, alte Integrationen zu überprüfen, werden einen Angreifer nicht stoppen, aber sie machen es möglich zu bemerken, wenn eine Adresse, von der Ihre Seiten abhängen, den Besitzer wechselt. Leser, die eine strukturierte Überprüfung wünschen, was ihre eigenen Websites laden und wie man mit der Überwachung beginnt, können sich ansehen, was AEU-I im Bereich Security-First-IT, Infrastruktur und Beratung bietet (https://aeu-i.com).