77 % von 433.000 Websites verwenden anfällige JavaScript-Bibliotheken

Letzte Woche haben wir unseren ersten jährlichen Bericht zum Stand der Open-Source-Sicherheit veröffentlicht. Eine der darin genannten Erkenntnisse: Eine Analyse von rund 433.000 Websites ergab, dass 77 % davon mindestens eine Frontend-JavaScript-Bibliothek mit einer bekannten Sicherheitslücke verwenden. Diese Zahl entspricht der Zahl, die wir bereits im März gemeldet haben. Dank Google Chromes Lighthouse, das jetzt mit Snyk auf anfällige JavaScript-Bibliotheken prüft, können wir jedoch deutlich umfassendere Ergebnisse erzielen.

Die Lighthouse-Daten werden im Rahmen des HTTP Archive erfasst und können über BigQuery abgefragt werden. So können wir Lighthouse-Prüfdaten in sehr großem Umfang analysieren.

Wie viele Websites sind anfällig?

Die BigQuery-Daten vom 15. Oktober (der jüngste verfügbare Durchlauf) enthalten Daten zu 439.176 verschiedenen URLs. Wenn wir URLs berücksichtigen, bei denen Lighthouse nicht ausgeführt werden konnte oder die Prüfung aus irgendeinem Grund nicht abgeschlossen wurde, erhalten wir einen Datensatz mit 418.112 verschiedenen Websites, den wir abfragen können.

Die erste Frage lautet: Wie viele dieser Websites weisen bekannte Sicherheitslücken auf? Mit einer Abfrage der Berichte können wir das herausfinden:

1SELECT
2  JSON_EXTRACT_SCALAR(report, "$.audits.no-vulnerable-libraries.score") AS score,
3  COUNT(0) AS volume
4FROM
5  [httparchive:har.latest_lighthouse_mobile]
6WHERE
7  report IS NOT NULL
8GROUP BY
9  score
10HAVING
11  score IS NOT NULL
12ORDER BY
13  score

Die Ergebnisse stimmen weitgehend mit unserer kleineren Untersuchung vom März überein: 77,3 % (323.132) dieser Websites haben die Prüfung nicht bestanden. Anders gesagt: 77,3 % dieser Websites enthalten mindestens eine clientseitige JavaScript-Bibliothek mit einer bekannten Sicherheitslücke. Die neue Version der HTTP-Archive-Website wird zeigen, wie sich dieser Wert im Laufe der Zeit verändert.

Wir können die Analyse noch vertiefen und ermitteln, wie viele bekannte Sicherheitslücken in diesen Bibliotheken stecken:

1SELECT 
2  REGEXP_EXTRACT(JSON_EXTRACT_SCALAR(report, "$.audits.no-vulnerable-libraries.displayValue"), r'^\S*') AS knownVulnerabilities,
3  COUNT(0) AS volume
4FROM
5  `httparchive.lighthouse.2017_10_15_mobile`
6WHERE
7  report IS NOT NULL
8AND
9  JSON_EXTRACT_SCALAR(report, "$.audits.no-vulnerable-libraries.score") = 'false'
10GROUP BY
11  knownVulnerabilities
12ORDER BY
13  CAST(knownVulnerabilities as int64)

Es zeigt sich: Wenn eine Bibliothek mindestens eine bekannte Sicherheitslücke aufweist, sind wahrscheinlich noch weitere vorhanden. 51,8 % der anfälligen Websites weisen mehr als eine bekannte Sicherheitslücke auf. Die meisten dieser Websites haben eine oder zwei, doch der lange Nachlauf ist beunruhigend: Auf 9,2 % der Websites werden Bibliotheken mit insgesamt mindestens vier bekannten Sicherheitslücken verwendet.

Welche Bibliotheken weisen am häufigsten Sicherheitslücken auf?

Anhand der Lighthouse-Prüfdaten können wir auch herausfinden, bei welchen Bibliotheken am häufigsten Sicherheitslücken festgestellt werden.

Zunächst können wir abfragen, welche Bibliotheken am häufigsten erkannt werden – unabhängig davon, ob sie anfällig sind. Die folgende Abfrage liefert die zehn am häufigsten gefundenen Bibliotheken:

1CREATE TEMPORARY FUNCTION getLibs(items STRING)
2RETURNS ARRAY<STRING>
3LANGUAGE js AS """
4  try {
5    return  items.match(/"name":"([^"]*)"/ig);
6  } catch (e) {
7    return [];
8  }
9""";
10
11SELECT library, COUNT(0) Volume
12FROM (
13   SELECT getLibs(JSON_EXTRACT(report, "$.audits.no-vulnerable-libraries.extendedInfo.jsLibs")) AS libs
14   FROM `httparchive.lighthouse.2017_10_15_mobile`
15)
16CROSS JOIN 
17   UNNEST(libs) AS library
18GROUP BY library
19ORDER BY Volume DESC
20LIMIT 10

Es überrascht nicht, dass jQuery an der Spitze der Liste steht. Das deckt sich mit unseren Ergebnissen vom März und entspricht vermutlich auch Ihren Erwartungen. Keine andere Bibliothek kommt bisher an die universelle Verbreitung von jQuery heran. Ein Vorbehalt: React wird derzeit zu selten erfasst. Sobald das aktualisierte Erkennungsskript in Lighthouse integriert ist, werden die Zahlen steigen (und wahrscheinlich auch der Gesamtanteil anfälliger Websites leicht zunehmen).

Sehen wir uns nun an, bei welchen Bibliotheken bekannte Sicherheitslücken festgestellt werden.

1CREATE TEMPORARY FUNCTION getLibs(items STRING)
2RETURNS ARRAY<STRING>
3LANGUAGE js AS """
4  try {
5    return  items.match(/"name":"([^"]*)"/ig);
6  } catch (e) {
7    return [];
8  }
9""";
10
11SELECT library, COUNT(0) Volume
12FROM (
13   SELECT getLibs(JSON_EXTRACT(report, "$.audits.no-vulnerable-libraries.extendedInfo.vulnerabilities")) AS libs
14   FROM `httparchive.lighthouse.2017_10_15_mobile`
15)
16CROSS JOIN 
17   UNNEST(libs) AS library
18GROUP BY library
19ORDER BY Volume DESC
20LIMIT 10

Die ersten paar Namen auf der Liste sind sehr ähnlich.

Die Prozentwerte zeichnen kein erfreuliches Bild. 92,5 % der jQuery-Versionen, die mit Abstand beliebtesten Bibliothek im Web, weisen in Produktionsumgebungen eine bekannte Sicherheitslücke auf. Tatsächlich sind sechs der zehn Bibliotheken, bei denen am häufigsten bekannte Sicherheitslücken gefunden werden, in der Mehrheit der in Produktionsumgebungen eingesetzten Versionen anfällig.

Dabei gibt es für jede Bibliothek auf dieser Liste Versionen, die nicht von diesen Sicherheitslücken betroffen sind.

Die Frontend-Bibliotheken, bei denen am häufigsten Sicherheitslücken festgestellt werden, sind seit ein bis fünf Jahren in Versionen ohne bekannte Sicherheitslücken verfügbar. In der Praxis werden Frontend-Bibliotheken und -Frameworks häufig nach ihrer Einführung in die Produktionsumgebung nicht mehr aktualisiert.

Grund zur Hoffnung

Die Lage ist derzeit ziemlich düster – das lässt sich nicht leugnen. Diese Daten bedeuten zwar nicht, dass alle 77 % dieser Websites ausgenutzt werden können (möglicherweise verwenden sie die anfälligen Methoden nicht), doch das ist nur ein kleiner Trost. Bei 77 % der Websites könnte schon ein einzelner Methodenaufruf durch eine Entwicklerin oder einen Entwickler genügen, um sie anfällig zu machen. Wie wir 2017 gesehen haben, müssen Sicherheitslücken in Open-Source-Software sehr ernst genommen werden.

Es gibt aber auch eine positive Seite. Obwohl in Produktionsumgebungen zahlreiche Sicherheitslücken vorhanden sind, wurden diese in den Bibliotheken selbst behoben. Für jede wichtige Bibliothek gibt es Versionen ohne bekannte Sicherheitslücken – wir müssen sie nur in die Produktionsumgebung übernehmen.

Damit sich die Lage verbessert, müssen wir einige Dinge ändern. Erstens brauchen wir bessere Tools und eine breitere Nutzung dieser Tools. Laut unserer Umfrage zum Stand der Open-Source-Sicherheit verwenden 38 % der Open-Source-Nutzenden keinerlei automatisierte Tools, um ihre Pakete aktuell zu halten. Ich würde darauf wetten, dass die Nutzung solcher Tools bei Frontend-JavaScript noch geringer ausfällt.

Dieser Wert sollte steigen. Verbesserungen an npm und Yarn haben die Verwaltung von Frontend-Paketen für Entwicklerinnen und Entwickler deutlich vereinfacht. Ein solider Paketverwaltungs-Workflow in Kombination mit Tools wie Snyk, die Ihnen helfen, Abhängigkeiten und die zugehörigen Pakete zu finden, verhindern, beheben und überwachen, trägt wesentlich dazu bei, das Web sicherer zu machen.

Zweitens muss das allgemeine Bewusstsein und Verständnis für das Problem wachsen. Deshalb haben wir den Bericht zum Stand der Open-Source-Sicherheit veröffentlicht: um die Herausforderungen bei der Absicherung von Open Source zu beleuchten und Lösungen zu finden, mit denen wir die Situation verbessern können.

Auch die Prüfung anfälliger Bibliotheken in Lighthouse (und Sonar) hilft. Mit diesen Tools können Entwicklerinnen und Entwickler Probleme auf den von ihnen erstellten Websites leichter erkennen. Dank HTTP Archive und BigQuery stehen uns außerdem problemlos zugängliche Daten zur Verfügung, mit denen wir die Verbreitung des Problems nachvollziehen können.

Die aktuellen Daten sind zwar wenig ermutigend, doch mit mehr Bewusstsein und besseren Tools lässt sich dieses Problem in Zukunft lösen.