Häufigkeit bekannter Schwachstellen in JavaScript-Bibliotheken

Letzte Woche wurde auf dem NDSS Symposium ein interessanter Bericht vorgestellt, der einen groß angelegten Versuch beschreibt, die Anfälligkeit clientseitiger JavaScript-Bibliotheken zu ermitteln.

Für die Studie wurde JavaScript-Code auf mehr als 133.000 verschiedenen Websites untersucht. Dabei suchten die Forschenden nach beliebten JavaScript-Bibliotheken (insgesamt 72), ermittelten die verwendeten Versionen und prüften anschließend, ob bekannte Schwachstellen vorlagen. Die Schlussfolgerungen waren gelinde gesagt interessant.

Der Bericht ist ausgezeichnet, und wir empfehlen Ihnen dringend, sich ein paar Minuten Zeit zu nehmen, um ihn zu lesen. Es gibt bereits einige Zusammenfassungen (Adrians ist besonders gelungen), und auch wir möchten unsere Perspektive teilen.

Bekannte Schwachstellen sind weit verbreitet

Die Forschenden stellten fest, dass 37 % der untersuchten Websites mindestens eine Bibliothek mit einer bekannten Schwachstelle enthielten. Diese Zahl sorgt in den Diskussionen, die wir verfolgt haben, für Unbehagen. Tatsächlich dürfte sie jedoch deutlich höher liegen.

In der Studie wurden die 72 beliebtesten Bibliotheken untersucht. Damit blieb eine große Zahl weniger populärer Bibliotheken unberücksichtigt. Das Medianprojekt, das wir beobachten, umfasst 184 Abhängigkeiten – die Vielfalt weniger verbreiteter Bibliotheken in der JavaScript-Entwicklung ist also beträchtlich. Jede dieser Bibliotheken wird zwar seltener verwendet, in der Summe sind es jedoch sehr viele. Bibliotheken am langen Ende dieses Spektrums haben zudem tendenziell weniger Mitwirkende. Wird eine Schwachstelle entdeckt, kann es daher ziemlich lange dauern, bis ein Update mit einer Fehlerbehebung bereitsteht.

Auch in der Liste der untersuchten Schwachstellen fehlten sicherlich einige. Die Forschenden fanden keine Schwachstellendatenbank, die ihren Anforderungen entsprach, und stellten daher nach bestem Wissen eine eigene zusammen. Das ist ihnen ziemlich gut gelungen, doch in unserer Datenbank gibt es offenbar mindestens einige Schwachstellen, die in ihrer Analyse nicht berücksichtigt wurden. So landete beispielsweise die Bibliothek moment auf ihrer Liste beliebter Bibliotheken, doch die zwei bekannten Schwachstellen, die viele Versionen betreffen, fanden sie offenbar nicht.

Auch neue Schwachstellen versuchten sie nicht zu identifizieren – was durchaus verständlich ist: Das Aufdecken neuer Schwachstellen erfordert viel Zeit und Aufwand, wie unser Forschungsteam sicher bestätigen kann. Doch neue Schwachstellen werden deutlich häufiger offengelegt, als Entwickler Bibliotheken aktualisieren. In den gerade einmal zehn Tagen seit Veröffentlichung des Berichts haben wir sieben neue Schwachstellen in npm-Bibliotheken hinzugefügt.

Wenn man all das zusammenzählt, wird klar: Wenn 37 % schon schlecht klangen, sieht die Wirklichkeit zweifellos noch schlimmer aus.

Außerdem sollte man nicht vergessen, dass sich diese 37 % ausschließlich auf die Client-Seite beziehen. Für npm-Pakete haben wir in unserer Datenbank derzeit rund 400 bekannte Schwachstellen, und nicht alle davon betreffen die Client-Seite. Eine Ausweitung der Studie auf das gesamte JavaScript-Ökosystem wäre noch ernüchternder.

Die Aktualisierung auf neue Bibliotheksversionen dauert lange

Auf der untersuchten Website mit dem Medianwert wurde eine Bibliotheksversion verwendet, die 1.177 Tage – also mehr als drei Jahre! – älter war als die neueste Version.

Die langsame Einführung neuer Software- und Bibliotheksversionen ist kein neues Problem und betrifft nicht nur das JavaScript-Ökosystem. Sehen Sie sich ein beliebiges Betriebssystem-Update an: Es dauert eine Weile, bis die meisten es installieren. Dabei haben diese Systeme in der Regel den Vorteil, dass sie Update-Benachrichtigungen direkt auf dem Gerät anzeigen können.

JavaScript-Bibliotheken stehen in puncto Sicherheit vor ganz ähnlichen Herausforderungen wie Betriebssysteme – allerdings ohne die Möglichkeit, Updates direkt auszulösen, und mit mehr manuellem Aufwand.

Eine Bibliothek zu aktualisieren, kostet Zeit und birgt Risiken. Zunächst muss man erfahren, dass ein Upgrade verfügbar ist, es herunterladen, testen und möglicherweise die eigene Verwendung der Bibliothek anpassen. Umfasst das Upgrade nur kleinere Änderungen und verändert die Funktionalität nicht wesentlich, ist der Aufwand etwas geringer – doch damit sinkt auch für viele der Anreiz zum Upgrade.

Eine korrekte SemVer-Versionierung kann Aufschluss über die Komplexität eines Upgrades geben, nicht aber über die Dringlichkeit eines Updates. Wie im Bericht erläutert, werden Fehlerbehebungen für Schwachstellen in den Versionshinweisen einer Bibliothek nicht immer klar kenntlich gemacht. Um die Dringlichkeit einer Version einzuschätzen, müssen Sie Ihre Bibliotheken auf bekannte Schwachstellen überwachen – und das tun die meisten Entwickler nach wie vor nicht.

Dennoch hoffnungsvoll

Die Ergebnisse des Berichts sind ein schmerzhafter Weckruf. Generell hat unsere Branche die zahlreichen Möglichkeiten der Open-Source-Entwicklung schnell genutzt, aber deutlich langsamer erkannt, welche Risiken damit einhergehen, und sich davor geschützt.

Auf den ersten Blick mögen die Ergebnisse entmutigend wirken (auch die Autoren des Berichts waren von ihren Erkenntnissen sicherlich ernüchtert), doch wir sind optimistisch. In letzter Zeit wächst das allgemeine Bewusstsein für die Bedeutung von Sicherheit langsam. Es wurden stärkere und intelligentere Webstandards entwickelt, die für zusätzliche Sicherheitsebenen sorgen. Auch die Tools werden besser. Sie können Ihre JavaScript-Anwendungen auf entwicklerfreundliche Weise auf bekannte Probleme überwachen und sich bei wichtigen neuen Updates benachrichtigen lassen.

Es liegt noch ein weiter Weg vor uns, doch JavaScript abzusichern ist ein lösbares Problem.