In den letzten Tagen wurde bekannt, dass die Domain polyfill.io, über die die bekannte JavaScript-Bibliothek Polyfill.js bereitgestellt wird, von einer chinesischen Firma übernommen wurde und nun Schadcode verbreitet.

Diese Bibliothek wird verwendet, um in älteren Browsern moderne Funktionen nachzurüsten, was man auch als Polyfill bezeichnet. Aufgrund der nun offengelegten Sicherheitslücke ist es dringend erforderlich, dass alle, die diesen Polyfill über polyfill.io eingebunden haben, sofort handeln, um ihre Websites und ihre Nutzer:innen zu schützen.

Was ist passiert?

Polyfill.js ist eine Open-Source-Bibliothek und kann sicher über Plattformen wie GitHub heruntergeladen und eingebunden werden. Häufig wurde dies nicht getan, sondern die Polyfill-Bibliothek wurde mittels Skript-Tag von der externen Domain polyfill.io heruntergeladen. Diese Domain wurde mittlerweile aber von einer chinesischen Firma übernommen, und statt der Originalversion wird nun eine manipulierte Version mit Schadcode ausgeliefert. Hier sind einige der Artikel, die das Problem im Detail beschreiben:

Warum Polyfill nicht mehr benötigt wird

Der Autor von Polyfill.js hat bereits darauf hingewiesen, dass man es nicht mehr verwenden soll. Das hat damit zu tun, dass ältere Browser, die diese Polyfills benötigen, mittlerweile einen sehr geringen Marktanteil haben. Modernen Browser hingegen benötigen keine Polyfills mehr. Solltest du alte Applikationen betreiben, die auf die Kompatibilität zu älteren Browser angewiesen ist, z. B. für interne Prozesse, kannst die gehosteten Alternativen von Polyfill.js bei Cloudflare oder Fastly nutzen oder noch besser eine eigene Version mit deiner Applikation bereitstellen, sodass du nicht von externen Quellen abhängig bist.

Maßnahmen zur Vermeidung solcher Angriffe

Diese Art von Angriffen nennt man Supply Chain Attack. Heutige Apps können aufgrund der Komplexität nicht komplett selbstständig entwickelt werden, sondern benötigen in der Regel externe Abhängigkeiten. Daher werden Supply Chain Attacks immer häufiger. Hier ein paar Maßnahmen, die du ganz generell ergreifen kannst, um deine Applikation auch vor ähnlichen Angriffen in Zukunft zu schützen.

Aktualisiert eure Bibliotheken: Nutzt nur vertrauenswürdige und aktuelle Bibliotheken.

Nutzt sichere Quellen: Ladet externe Bibliotheken direkt von vertrauenswürdigen Quellen wie GitHub herunter, um sicherzustellen, dass ihr die Originalversion verwendet. Nutzt keine Ressourcen von externen CDNs, wenn dies nicht notwendig ist. Ladet die benötigten Dateien herunter und stellt sie über eure eigene App bereit. Dies gibt euch die Kontrolle darüber, welche Version der Datei verwendet wird, und schützt euch vor unerwünschten Änderungen durch Dritte. Mit dem Aufkommen von HTTP/2 sind die früheren Vorteile von CDNs, wie schnelleres Laden und geringere Latenz bei der Integration von Assets geringer geworden. CDNs sind weiterhin sinnvoll, wenn der gesamte Inhalt darüber ausgeliefert und damit beschleunigt wird.

Verwendet Subresource Integrity (SRI): SRI erlaubt es, eine Integritätsprüfung (einen Hash) anzugeben, um sicherzustellen, dass der heruntergeladene Inhalt nicht verändert wurde. Hier ein Beispiel:

<script src="https://cdnjs.cloudflare.com/polyfill/v3/polyfill.min.js?version=4.8.0" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxFf/2g+7t1LZ8q7v6AJN0GRd3vZ1sT" crossorigin="anonymous"></script>

Mit SRI wird das Skript nur geladen, wenn der Hash des heruntergeladenen Skripts mit dem angegebenen Hash übereinstimmt. Wenn der Inhalt geändert wurde, lädt der Browser das Skript nicht.

Verwendet Content Security Policy (CSP): Implementiert eine Content Security Policy, um zu kontrollieren, welche Skripte und Ressourcen auf euren Webseiten geladen werden dürfen. Eine CSP kann das Nachladen von Schadcode von nicht autorisierten Domains unterbinden. Zum Beispiel hätte eine CSP in diesem Fall das Laden von Schadcode von www.googie-anaiytics.com verhindert.

Um CSP in einer nginx-Konfiguration zu aktivieren, könnt ihr folgenden Code verwenden:

add_header Content-Security-Policy "script-src 'self' https://cdnjs.cloudflare.com/polyfill/v3/polyfill.min.js?version=4.8.0";

Diese Richtlinie erlaubt nur Skripte von der eigenen Domain (self) und von cdnjs.cloudflare.com. Da der Schadcode von einer anderen Domain nachgeladen wird, hätte die CSP dies verhindert.

Bleibt informiert: Abonniert Sicherheitsupdates und informiert euch regelmäßig über potenzielle Bedrohungen.

Indem ihr diese Maßnahmen befolgt, könnt ihr das Risiko von Supply Chain Angriffen erheblich reduzieren und die Sicherheit eurer Websites gewährleisten.