385.000 Seiten verbreiten Schadsoftware: Unterschätztes Risiko externer Abhängigkeiten im Web

Als Video ansehen
Bereitgestellt über YouTube

385.000 Seiten verbreiten Schadsoftware: Unterschätztes Risiko externer Abhängigkeiten im Web

Sicherheit DMW007

Dieser Lieferkettenangriff eröffnet für das Web eine neue Dimension: Rund 385.000 Hosts verbreiten Schadsoftware von Polyfill[.]io. Und das, obwohl Polyfills in den meisten Fällen gar nicht mehr gebraucht wird. Dieser Fall zeigt aber ein weiteres Grundsatzproblem von vielen Webentwicklern – der sorglose Umgang mit externem Code sowie externen Abhängigkeiten. Im Detail zeigt dir das dieser Beitrag zusammen mit verschiedenen Lösungsmöglichkeiten.

Was ist ein Polyfill und wofür braucht man das?

Allgemein handelt es sich bei einem Polyfill (oft auch Shim genannt) um Programmcode, der moderne Funktionen nachrüstet, der (noch) nicht offiziell unterstützt wird. Es ist also eine Kompatibilitätsschicht. Polyfills kann es nahezu überall geben, beispielsweise in PHP und Python. Erst PHP 8 brachte die Funktion str_starts_with, um zu prüfen, ob eine Zeichenkette mit einer bestimmten anderen Zeichenkette beginnt.1 Bis dahin musste man sich selbst behelfen, etwa über strpos.2 Der Code war teils aufwändiger oder zumindest weniger lesbar.

Üblicherweise prüft ein Polyfill, ob er benötigt wird. Im besten Falle etwa, ob eine bestimmte Funktion oder Funktionalität vorhanden ist – nur dann aktiviert er sich. Manche fragen auch Softwareversionen ab. Sauber umgesetzt lässt er modernerer Software den Vorzug falls möglich, da deren native Implementierungen oft performanter sind.

Polyfills im Web für ältere und unbelehrbare Browser

Bei Polyfill[.]io geht es um das Web, daher schauen wir uns die Webbrowser in diesem Abschnitt genauer an. Sehr viele Polyfills beziehen sich hier auf den Internet Explorer: Microsofts Browser erreichte um die Jahrtausendwende als „Gewinner“ des ersten Browserkrieges eine Quasi-Monopolstellung mit über 90% Marktanteil (2003).3Allgemein handelt es sich bei einem Polyfill (oft auch Shim genannt) um Programmcode, der moderne Funktionen in Webbrowsern nachrüstet, die ihn (noch) nicht unterstützen. Es ist also eine Kompatibilitätsschicht. Mehrheitlich bezieht sich das auf den Internet Explorer: Microsofts Browser erreichte um die Jahrtausendwende als „Gewinner“ des ersten Browserkrieges eine Quasi-Monopolstellung mit über 90% Marktanteil (2003).

Nach diesem „Sieg“ sah der Konzern keine Notwendigkeit mehr, über 100 Millionen US-Dollar pro Jahr für mehr als 1.000 Mitarbeiter in das Projekt zu stecken.4 Der Browser verlor den Anschluss und hinkte der aufstrebenden Konkurrenz (anfangs vor allem Mozilla Firefox) immer weiter hinterher. Zwar sanken die Marktanteile, doch als Standardbrowser in Windows konnten es sich viele nicht leisten, ihn zu vernachlässigen. Wer neue Funktionen nutzen wollte, musste daher meist Hacks einbauen, damit die Seite zumindest einigermaßen auch im IE funktionierte. Er wird daher oft als meistgehasster Browser der Welt bezeichnet.5 Umfragen unter Entwicklern belegen das.6

Teilweise brauchte man auch für andere Browser Polyfills/Shims, zumindest zeitweise. Bei vielen Funktionen zogen die meisten Browser mit der Zeit nach.7 Ungeschlagen bleibt jedoch Microsofts Internet Explorer, weil Microsoft gezielt Standards untergräbt. Webseiten sollten für den IE entwickelt und nur dort so aussehen wie sie sollten, damit Nutzer gezwungen sind, Microsofts Browser zu verwenden. Für ihn gab es extra conditional comments, um HTML exklusiv für den IE oder bestimmte Versionen (z.B. hier kleiner als IE9) zu laden:8

<!--[if lt IE 9]>
<script src="https://html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

In diesem Beispiel geht es um HTML5. Die Auszeichnungssprache für Webseiten erschien 2008, doch der IE unterstützte sie selbst in der letzten Version 11 bis zum Ende hin nur vereinzelt. Das gleiche gilt für CSS zur Gestaltung von Webseiten.9 Einen Eindruck vermittelt folgender Auszug:

Auch bei der Skriptsprache JavaScript sieht es kaum besser aus: Das 2015 veröffentlichte ECMASkript 2015 (ES6) beispielsweise unterstützt selbst der aktuellste IE 11 nur teilweise.10 Dies ist jeweils nur ein Auszug. HTML, CSS und JavaScript sind über die Jahre sehr mächtig geworden. Der IE hatte Mühe, nicht noch weiter abgehangen zu werden, als ohnehin schon.11

Was ist Polyfill[.]io und was ist damit passiert?

Es existieren eine ganze Reihe an Bibliotheken, um diverse Funktionen bei Bedarf in älteren Browsern nachzurüsten oder zu vereinheitlichen. Eine der bekanntesten im JavaScript-Bereich ist beispielsweise jQuery: Sie wurde in Version 1.0 im Jahr 2006 vorgestellt12 und soll einheitlichen JS-Code über verschiedene Browser hinweg ermöglichen. Der Grundgedanke ist im Kern immer gleich – man bindet eine Bibliothek ein und muss sich im besten Falle nicht mehr großartig um unterschiedliche Webbrowser kümmern. Stattdessen sorgt die Bibliothek dafür, dass eine bestimmte Funktion überall gewährleistet ist.

Eine solche hat Andrew Betts entwickelt: Er schuf polyfill-service13 als quelloffenes Projekt.14 Doch über die Domain polyfill[.]io habe er nie Kontrolle gehabt.15 Anhand des Git-Verlaufs lässt sich belegen, dass er 2014 den ersten Commit in diesem Repository ausführte.16

Interessant ist, dass polyfill[.]io erstmals 2013 in der README des Projekts verlinkt wird.17 Die Domain existiert also seit geraumer Zeit und wurde laut bisherigen Informationen an ein chinesisches Unternehmen verkauft.18 Dort hat man die ehemals von Fastly bereitgestellten Inhalte umgezogen.19 Anschließend wurde das dort ausgelieferte JavaScript mit Schadcode verseucht, der Besucher auf Webseiten für Sportwetten und andere Erwachseneninhalte umleitet. Dieser scheint nicht kontinuierlich an jeden ausgeliefert zu sein, um die Entdeckung zu erschweren. Laut Berichten eines Betroffenen beispielsweise nur an Mobilgeräte.20

Wer ist betroffen?

Inzwischen wurde die Domain polyfill[.]io von der Registrierungsstelle abgeschaltet. Auch andere Anbieter wie Google hat das Ausspielen von Werbung an Seiten gestoppt, die JS von dieser Domain eingebunden hatten. Dass derartige Maßnahmen ergriffen wurden, liegt am immensen Ausmaß: Publicwww erlaubt das Durchsuchen von technischen Aspekten vieler Webseiten. Kostenfrei lassen sich die beliebtesten 3 Millionen Seiten durchsuchen. Hier ist die polyfill-Domain in rund 477.000 der indexierten Seiten eingebunden.21 GitHub liefert über 207.000 betroffene Dateien, in denen die Domain referenziert wird.22

Darunter sind bekannte, große Seiten mit starker Reichweite. Ein paar Beispiele: The Guardian, Buzzfeed, Breithart, The Verge, The Epoch Times, Ars Technica, Nintendo, Metro (GB), Finanztip (467.000 Abonnenten auf YT), Weltbild, RTL2, Neckermann-Reisen und viele mehr. Immerhin rund 5.800 Seiten mit .de Domainendung sind darunter.23

Hierbei ist zu bedenken, dass Andrew Betts bereits am 25.02.2024 zum ersten Mal gewarnt hat. Es dauerte Monate, bis sich die Information verbreitet hat. In unseren Medien sind viele erst Ende Juni darauf aufmerksam geworden.24 Anfang Juli die Ergänzung der Zahlen von anfangs 100.000 auf auf rund 400.000 Hosts.25 Auch uBlock Origin hat erst am 25.06.2024 reagiert und die Domain in ihre Liste schadhafter Seiten aufgenommen.26 Dieser Bis heute haben manche Betreiber nicht reagiert und binden die Domain immer noch ein. Man kann sich kaum vorstellen, wie groß das Schadpotenzial bei derart vielen Seiten über einen langem Zeitraum gewesen sein muss.

Als Nutzer seid ihr relativ machtlos und müsst darauf vertrauen, dass Sicherheit für die Seitenbetreiber nicht nur Lippenbekenntnisse sind.

Was ihr daraus lernen könnt und solltet

Es gibt nun zwei Möglichkeiten: Wir tauschen das CDN aus, schimpfen auf die bösen Chinesen und laufen ins offene Messer (bzw. lassen die Nutzer ins offene Messer laufen). Dann machen wir weiter wie bisher, um beim nächsten Angriff das gleiche zu tun – Scherben aufkehren und zurück zum Tagesgeschäft. Die nächsten Angriffe laufen bereits: Es gibt Hinweise darauf, dass alleine dieser Akteur vier weitere Domains (bootcdn[.]net, bootcss[.]com, staticfile[.]net, and staticfile[.]org) kontrolliert.27

Oder wir verstehen, durch welche grundlegenden Denkfehler derartige Angriffsflächen überhaupt erst geschaffen werden. Vieles kann getan werden, um das zu verhindern oder wenigstens den Schaden stark einzudämmen. U-Labs ist beispielsweise nicht betroffen – obwohl ich bei weitem nicht die Ressourcen von RTL2 oder einem anderen Unternehmen mit Milliardenumsatz habe. Das ist kein Zufall, daher befasst sich dieser Abschnitt mit den Ursachen und Möglichkeiten, was ihr besser machen könnt, um von den nächsten CDN-Hacks nicht betroffen zu sein – und nebenbei noch etwas gutes für die Privatsphäre eurer Besucher zu tun.

Drittanbieter-Abhängigkeiten sind ein Sicherheitsrisiko!

Man sollte sich erst mal grundsätzlich im klaren werden: Fremder Code ist ein Sicherheitsrisiko. Sobald ich Code von anderen bei mir einbette, muss ich dem voll vertrauen können. Der Entwickler kann Schadcode einbauen oder seine Sicherheit vernachlässigen und gehackt werden. Weitere Szenarien wie hier durch den Verkauf geschehen sind ebenfalls denkbar. Wenn ich jemandem einen Schlüssel zu meiner Wohnung gebe, ist das ein Risiko. Diese Person kann jederzeit rein kommen und alles mögliche machen. So ist es auch hier und dem muss man sich bewusst werden.

Es ist ein kritischer Trend, dass bei vielen Entwicklern offenbar blind fremder Code ausgeführt wird. Mein absurdestes Parabeispiel dafür ist das NodeJS Paket is-even.28 Das hat derzeit rund 121.000 Downloads pro Woche (!) und verweist auf ein zweites Paket is-odd mit über 256.000 wöchentlicher Downloads (!!), dessen Rückgabewert es negiert (!!!). Das wiederum verweist auf is-number als Abhängigkeit mit rund 64.262.000 (!!!!!) Installationen innerhalb von sieben Tagen. Zufälligerweise liegen die wenigstens beim gleichen Entwickler. Üblich für das JS-Ökosystem wären ein riesiger Baum mit hunderten Abhängigkeiten über zig Personen, denen ihr alle vertraut!

Der Kernpunkt ist hier aber ein anderer: In so ziemlich jeder Sprache kann man mit dem Modulo-Operator in einer einzigen Codezeile prüfen, ob eine Zahl gerade oder ungerade ist. Selbst JavaSkript kann das!

let isOdd = (number % 2) == 0

Jede Woche lädt sich also eine hohe 6-Stellige Zahl an Projekten eine potenzielle Remote Code Execution Lücke ins Projekt, wegen einer Codezeile. Nicht wegen hochkomplexen Berechnungen, für die man Mathematik studiert und 100.000 Zeilen selbst programmieren müsste. Wegen einer Zeile, die nicht mal kürzer ist, als die Funktion aufzurufen.

Das steht in absolut keinem Verhältnis und zeigt klar: Wer so was tut, hat weder davon ein Verständnis. Noch scheint er überhaupt zu wissen, was er da tut. Damit ist er in guter Gesellschaft. Der Entwickler von diesen drei Paketen schreibt selbst:

I created this in 2014, when I was learning how to program.

Jon Schlinkert

Einer hat also keine Ahnung, veröffentlicht unnötige Pakete. Und hunderttausende folgen dem blind. Wer vorne steht, wird schon wissen, was er tut… Mit der Einstellung werden wir bei der Sicherheit nicht einen Schritt weiter kommen. Sondern ständig die gleichen Bruchbuden bauen und bloß den Schutt aufräumen, wenn wieder mal eine zusammen bricht. Dieser Vergleich ist nicht übertrieben wenn ihr euch – insbesondere im JS-Umfeld – mal anschaut, wie viele Abhängigkeiten da drin stecken. Das sind schnell 5-20 direkte Pakete und da hört es ja nicht auf. Jedes Paket bringt noch mal mindestens so viele mit, sodass man am Ende schnell im 3-Stelligen Bereich landet.

Stattdessen müssten externe Abhängigkeiten äußerst sorgsam eingesetzt werden: Brauche ich dafür wirklich eine fremde Bibliothek, oder schreibe ich die 10 Zeilen selbst und bin unabhängig? Wenn es sein muss, wer hat die entwickelt? Ist das seriös oder fallen die regelmäßig damit auf, z.B. ihre Sicherheit zu vernachlässigen? Welche Alternativen gibt es?

Brauche ich das überhaupt (noch)?

Alles ändert sich, das ist auch im Web so: Was heute notwendig ist, kann es in ein paar Jahren schon nicht mehr sein. Unnötiger Code ist ebenfalls ein Sicherheitsrisiko, er steigert die Angriffsfläche. Wenn ich 5 Autos an unterschiedlichen Standorten habe, ist das Risiko, dass eines davon mal geklaut oder aufgebrochen wird, höher als mit einem. Brauche ich die gar nicht alle, setze ich mich also einem unnötig hohen Risiko ohne Mehrwert aus.

Das sollte einleuchten und ist in der Softwareentwicklung wenig anders: Code enthält Fehler, je mehr Code um so mehr Fehler habe ich – selbst wenn dieser lokal liegt. Sicherheitstechnisch ist es daher sinnvoll, ein Projekt regelmäßig einem Frühjahrsputz zu unterziehen: Wird etwas nicht mehr gebraucht, entfernt man es. Bei Polyfills sind wir nämlich nicht mehr im Jahre 2010. Der IE ist seit 2022 offiziell tot29 und bei den verbleibenden Browsern haben die Abstände abgenommen. JS ES6 wird seit ca. 2016 von allen Browsern komplett unterstützt. Die letzte Ausnahme war der Internet Explorer 11. Was an relevanten Funktionen übrig bleibt (wie z.B. Web Bluetooth30), kann man oft gar nicht per Polyfill lösen.

Auch heute noch gibt es Webseiten, die uralte Hacks für den IE einbinden. Dass diese Frage wohl kaum gestellt wird hat dazu beigetragen, dass extrem viele Seiten verwundbar sind. Derartiges Aufräumen ist unbeliebt, weil es Ressourcen kostet, von denen Chef und Nutzer nichts sehen.

Externe Abhängigkeiten erfordern regelmäßige Wartung

Dennoch ist es notwendig, eben so wie externe Abhängigkeiten kontinuierlich gepflegt werden müssen. Ansonsten vergammelt eure Codebasis wie bei Atlassian: Dort hat man eine externe Bibliothek eingebaut, die 2018 ein Sicherheitsupdate veröffentlichte. Da offensichtlich niemand Updates einspielte, korrigierte Atlassian sie erst 2022. Sämtliche Kunden waren mindestens 4 Jahre lang für Remote Code Execution verwundbar – absolut vermeidbar.

Das Unternehmen hat seine Nutzer ins Messer laufen lassen, weil es grundlegende Hausaufgaben nicht machte. Es ist daher nicht verwunderlich, dass auch hier Atlassian wieder ganz vorne mit dabei ist: Sie setzen unter atlassian.com ebenfalls auf das verwundbare CDN.3132

Seitenbetreiber haben an dieser Stelle eine Verantwortung für ihre Nutzer. Eben so wie jedes Ladengeschäft sich um die Sicherheit seiner Kunden kümmern muss.

CDNs: Uneingeschränktes Laden fremden Codes auf Webseiten ist das nächste Sicherheitsrisiko

Sollte man sich nun für eine zwingend nötige Bibliothek entscheiden, bindet man diese nicht über Server des Entwicklers, oder gar andere Quellen wie CDNs ein. Damit kann dieser in vielen Fällen uneingeschränkt in Echtzeit Code im Browser jedes Besuchers ausführen. Im schlimmsten Falle müsst ihr nun weiteren Parteien vertrauen: Dem CDN-Anbieter, seinen Hostern usw. Darüber hinaus können CDN-Anbieter eure Besucher dadurch verfolgen. Sie sehen jede Anfrage und können mindestens sein Verhalten bei euch analysieren. Größere sogar über verschiedene Domains hinweg.

Und nein, auch ein bekannter Anbieter ist nicht automatisch sicher. 2021 wurde beispielsweise ein erfolgreicher Hack von cdnjs demonstriert.33 Das ist nicht irgendein Anbieter, sondern hat rund 47% Marktanteil. 12,6% aller Webseiten weltweit (!) laden mindestens ein Skript von dort,34 d.H. man konnte dort beliebig Code ausführen. Ironischerweise werben genau die damit, Lieferkettenangriffe zu Reduzieren, in dem man lieber ihre Kopie auf cdnjs einbindet.35 Wer meinen Punkt nur ansatzweise verstanden hat, erkennt die offensichtliche Nebelkerze. Als würde Burger King damit werben, man solle sich seinen BigMac doch lieber der Gesundheit zuliebe bei ihnen holen!

Vergesst allgemein den Gedanke, bei einem großen Unternehmen sei alles viel besser oder gar sicherer. Microsoft ist Marktführer und lässt sich andauernd hacken. Nur weil man theoretisch die Ressourcen für maximal mögliche Sicherheit hätte, muss man sie nicht zwingend dafür einsetzen. Das sind Wirtschaftsunternehmen, deren Ziel ist Geld verdienen. Also liefern sie nicht das beste Produkt, sondern nur eines was gerade gut genug ist, um maximale Profite zu erwirtschaften.

Dazu kommt, dass CDNs für die meisten Seiten ebenfalls unnötig sind. Ein CDN ist überhaupt erst eine Erwägung wert, wenn große Dateien weltweit schnell verfügbar gemacht werden sollen. Bei zu großen Dateien habt ihr wahrscheinlich schon den vorherigen Fehler gemacht und euer Projekt mit Abhängigkeiten vollgestopft. Weltweit trifft das für eine Hand voll Projekte zu, nicht das gesamte Internet. Meine lokale Zeitung beispielsweise hat keinen technisch ansatzweise rechtfertigbaren Grund, um jQuery von deren CDN zu laden, Angular von Cloudflare und diversen weiteren Fremddomains. Fehlt nur noch, dass irgendwo steht „Ihre Sicherheit ist uns wichtig“. Wenn sie das wirklich wäre, würde man wirklich benötigtes externes CSS, JS & co. auf die eigenen Server legen. Kontrolliert Versioniert. Im besten Falle geprüft vor Aktualisierungen – es ist ja immer noch fremder Code.

Müssen es externe CDNs sein, nutzt wenigstens den Integritäts-Hash

Für die Minderheit, bei denen ein CDN aus o.g. Gründen tatsächlich sinnvoll sein sollte, gibt es noch eine weitere, recht unbekannte Maßnahme: Das integrity Attribut.36 Es kann für CSS & JS Elemente eingesetzt werden und enthält eine Prüfsumme (Hash) der Zieldatei. Bootstrap baut das löblicherweise inzwischen in ihren CDN Beispielcode zum Kopieren ein:

<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-QWTKZyjpPEjISv5WaRU9OFeRpok6YctnYmDr5pNlyT2bRjXh0JMhjY6hW+ALEwIH" crossorigin="anonymous">
<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/js/bootstrap.bundle.min.js" integrity="sha384-YvpcrYf0tY3lHB60NNkmXc5s9fDVZLESaAA55NDzOxhy9GkcIdslK1eN7N6jIeHz" crossorigin="anonymous"></script>

Das schützt euch nicht vor allem Gefahren eine CDNs! Beispielsweise, wenn obiges Beispiel bereits Schadcode enthalten ist (der ggf. erst später nachgeladen wird). Auch dem Verfolgen durch den Anbieter setzt ihr eure Nutzer weiterhin aus. Allerdings verhindert er wenigstens nachträgliche Manipulation. Angenommen, obiger Code ist geprüft und sauber, den bettet ihr ein. Morgen wird jsdelivr.net gehackt und fügt dort Schadsoftware ein. Dann ändert sich die Prüfsumme und alle gängigen Browser laden die Datei nicht mehr in eure Webseite. Zumindest davor wären die Besucher also geschützt. Es reduziert die Angriffsfläche also – dennoch bleibt lokales Einbinden das Mittel der Wahl.

Fazit

Wer immer noch unreflektiert Drittanbieter-Dienste in seine Webseite einbindet, sollte spätestens nach diesem Vorfall endlich anfangen, sich mit dem Thema Sicherheit zu beschäftigen. Und zwar ernsthaft. Drittanbieter-Abhängigkeiten bergen viele Risiken, die den meisten scheinbar bis heute kaum oder gar nicht bewusst zu sein scheinen. Sie werden daher weiterhin sorglos eingesetzt – mit entsprechenden Folgen.

Es ist nicht der erste erfolgreiche Angriff, noch wird es der letzte sein. Wer lediglich von Anbieter A zu B umzieht, ohne die o.g. Punkte kritisch zu hinterfragen, hat das Kernproblem nicht verstanden – und setzt sich bzw. seinen Besuchern damit einem hohen, oft vermeidbaren Risiko aus. Die gern eingesetzte Floskel „Ihre Sicherheit ist uns sehr wichtig“ oder auch „Der Schutz Ihrer Daten hat für uns höchste Priorität“ hilft dabei keinem. Sicherheit muss gelebt und nicht bloß in PR-Erklärungen schön klingend behauptet werden.

Quellen

  1. https://www.php.net/manual/en/function.str-starts-with.php ↩︎
  2. https://gist.github.com/juliyvchirkov/8f325f9ac534fe736b504b93a1a8b2ce ↩︎
  3. https://developer.mozilla.org/en-US/docs/Glossary/Polyfill ↩︎
  4. https://www.lambdatest.com/web-technologies/es6-ie ↩︎
  5. https://www.theverge.com/2014/4/8/5593584/the-most-hated-browser-in-the-world-is-finally-dead ↩︎
  6. https://www.techradar.com/news/internet-explorer-voted-the-worst-thing-about-using-the-web ↩︎
  7. https://www.zealoussites.com/blog/why-do-web-developers-hate-internet-explorer ↩︎
  8. https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/ms537512(v=vs.85)?redirectedfrom=MSDN ↩︎
  9. https://caniuse.com/?compare=ie+6,ie+7,ie+8,ie+9,ie+10,ie+11&compareCats=CSS,HTML5,JS,JS%20API,Other,Security,SVG ↩︎
  10. https://caniuse.com/?compare=ie+6,ie+7,ie+8,ie+9,ie+10,ie+11&compareCats=JS ↩︎
  11. https://www.infoworld.com/article/2685998/five-things-ie-still-doesnt-have-and-six-things-it-might-someday.html ↩︎
  12. https://blog.jquery.com/2006/08/26/jquery-10/ ↩︎
  13. https://github.com/polyfillpolyfill/polyfill-service/commit/0db3060d8d99112a41d9600ae15832af01fffef6 ↩︎
  14. https://github.com/polyfillpolyfill/polyfill-service ↩︎
  15. https://x.com/triblondon/status/1761852117579427975 ↩︎
  16. https://github.com/polyfillpolyfill/polyfill-service/commits/main/?since=2014-07-01&until=2014-07-31&after=41a4cfc259d371ce8055d3e0702f230019bc7731+104 ↩︎
  17. https://github.com/polyfillpolyfill/polyfill-service/commit/09b75df8387a750d79e643c1ccde73774129c2ae ↩︎
  18. https://web.archive.org/web/20240318120623/https://github.com/polyfillpolyfill/polyfill-service/issues/2834 ↩︎
  19. https://cside.dev/blog/the-polyfill-attack-explained ↩︎
  20. https://github.com/polyfillpolyfill/polyfill-service/issues/2873#issuecomment-2182491302 ↩︎
  21. https://publicwww.com/websites/%22polyfill.io%22/ ↩︎
  22. https://github.com/search?q=https%3A%2F%2Fpolyfill.io%2Fv&type=code ↩︎
  23. https://publicwww.com/websites/%22polyfill.io%22+site%3Ade/5 ↩︎
  24. https://www.golem.de/news/angriff-via-polyfill-io-ueber-100-000-webseiten-verbreiten-ploetzlich-malware-2406-186452.html ↩︎
  25. https://www.golem.de/news/grossteil-aus-deutschland-fast-400-000-webhosts-verbreiten-malware-via-polyfill-io-2407-186716.html ↩︎
  26. https://github.com/uBlockOrigin/uAssets/pull/24255 ↩︎
  27. https://www.securityweek.com/over-380k-hosts-still-referencing-malicious-polyfill-domain-censys/ ↩︎
  28. https://www.npmjs.com/package/is-even ↩︎
  29. https://futurezone.at/digital-life/grabstein-grab-internet-explorer-suedkorea-meme-viral-tot-microsoft/402045145 ↩︎
  30. https://caniuse.com/?search=web%20bluetooth ↩︎
  31. https://trends.builtwith.com/websitelist/Polyfill-IO ↩︎
  32. https://www.wappalyzer.com/technologies/javascript-libraries/polyfill/ ↩︎
  33. https://cside.dev/blog/the-2021-cdnjs-vulnerability ↩︎
  34. https://w3techs.com/technologies/overview/content_delivery ↩︎
  35. https://blog.cloudflare.com/polyfill-io-now-available-on-cdnjs-reduce-your-supply-chain-risk ↩︎
  36. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity ↩︎

Leave a Reply