Das Internet wird gerade zu einem immer unsichereren Ort. In den letzten Wochen gab es mehrere sehr signifikante Sicherheitslücken: php2shell, nodejs, brotli.
Diese Probleme kommen nicht aus dem Nichts, sondern sie sind Folge der Entwicklungen der KI-Firmen im Sicherheitsbereich. Es werden mehr Lücken entdeckt, die schon immer da waren. Und es werden mehr entdeckte Lücken geschlossen.
Trotzdem sind diese Lücken nur geschlossen, wenn auch der Seitenbetreiber einer Internetinfrastruktur die Lücke schließt. Für Deine eigene Domain kannst Du das sicherstellen. Du hast Backups, einen Updatefahrplan, der Deine Bibliotheken aktuell hält und einen Red-Teaming-Prozess, indem Du regelmäßig prüfst, ob es Sicherheitsprobleme in Deiner Architektur gibt.
Aber: Das sichert nur Deine eigene Architektur ab. Alle eingebundenen externen Ressourcen sind ein inzwischen nicht mehr vertretbares Sicherheitsrisiko. Jede noch so kleine Third-Party-Ressource ist ein Problem für die Sicherheit Deiner User.
Wenn der Anbieter des JavaScripts eine Sicherheitslücke hat, dann kann ein „Bad Actor“ das nutzen, um Schadcode an Deine Nutzer zu verteilen. Du denkst, das ist ein theoretisches Problem und passiert nur Unternehmen, die keine professionelle IT haben? Dann solltest Du Dir den Case von Polymarket ansehen:
- Polymarket hatte ein kleines Script zum Messen von Ladezeiten von DebugBear auf der Seite.
- DebugBear ist auch eine Firma mit einem ordentlichen Team. Aber DebugBear wurde gehackt.
- Der Hacker hat daraufhin das Script geändert und Millionen von Polymarket-Usern abgegriffen. Autsch.
Das heißt nicht, dass Du komplett auf Third-Party verzichten musst. Deine Risiko-Evaluation sollte aber eine andere sein. Kopiere die Scripte auf Dein eigenes Ökosystem, damit Du das Update der Scripte in der Hand hast (mit http/2 ist das eh (minimal) besser für Ladezeiten). Das ist unbequem. Aber Sicherheit ist unbequem. Diese Unbequemlichkeit in Kauf zu nehmen ist heute notwendiger als vor einem Jahr.
Dan Robinson von Detail.dev hat es auf Twitter richtig gesagt:
> "I hate to write this because I spent a good chunk of my 20s benefitting from product teams taking a chance on a nothing startup and installing our js on their site. But in the past two weeks this risk vector has exploded. It's better for the ecosystem if we move away from third party js as fast as we can."
Die Todo-Liste für die nächsten Wochen:
- JavaScript Crawl aller Seiten (mit vollständigem Cookie-Consent)
- Auswertung aller eingebauten JavaScripte und anderer Third-Party-Ressourcen
- Welche davon brauchst Du? Was kostet es das Unternehmen, darauf zu verzichten?
- Welche bleiben über? Wie sieht der Security-Audit für diese Ressourcen aus? Welche Firma? Sind Updates sinnvoll/erwartbar? Müssen wir das Script unbedingt von einer fremden Domain laden? Wenn ja: Wie kann ich mich gegen unbemerkte Updates absichern?
- Wie stelle ich sicher, dass wir nicht neue ungeprüfte Dinge einbauen?
Du denkst immer noch, ich spaße? Ich meine das sehr, sehr ernst.
Risiken für Deine Nutzer gibt es bereits über nicht gehackte Anbieter. Neulich erst ist ein Zero-Click-Exploit aufgeflogen, der gezielte User adressiert hat, die nur eine Seite mit Google, Yandex oder anderen großen Display-Ad-Netzwerken aufrufen mussten. Und schwupps ist die Malware installiert.
Ganz neu ist das nicht. Schon in den letzten Wochen sind Domains aufgefallen, die gezielt gekauft worden sind, um Malware zu verteilen (unter anderem gezielt iOS exploits). Aber warum kaufen, wenn es mit Hacking noch billiger geht?