77 % des 433 000 sites utilisent des bibliothèques JavaScript vulnérables

La semaine dernière, nous avons publié notre premier rapport sur l’état de la sécurité de l’open source. Parmi les découvertes mentionnées dans le rapport, une analyse d’environ 433 000 sites a révélé que 77 % d’entre eux utilisent au moins une bibliothèque JavaScript front-end présentant une vulnérabilité de sécurité connue. Ce chiffre est conforme à celui que nous avions communiqué en mars, mais grâce à Lighthouse de Google Chrome, qui teste désormais les bibliothèques JavaScript vulnérables avec Snyk, nous pouvons obtenir des résultats beaucoup plus complets.

Les données de Lighthouse sont recueillies dans le cadre de HTTP Archive et peuvent être interrogées via BigQuery. Nous pouvons ainsi interroger à très grande échelle les données d’audit de Lighthouse.

Évaluer le nombre de sites vulnérables

Les données du 15 octobre (la dernière exécution disponible) dans BigQuery contiennent des informations recueillies à partir de 439 176 URL différentes. Après avoir exclu les URL pour lesquelles Lighthouse n’a pas pu s’exécuter ou dont l’audit n’a pas abouti pour une raison ou une autre, nous obtenons un ensemble de données portant sur 418 112 sites différents.

La première question consiste à déterminer combien de ces sites présentent des vulnérabilités connues. Nous pouvons interroger les rapports pour obtenir cette information :

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

Les résultats sont tout à fait cohérents avec notre étude à plus petite échelle menée en mars : 77,3 % (323 132) de ces sites n’ont pas réussi l’audit. Autrement dit, 77,3 % de ces sites contiennent au moins une bibliothèque JavaScript côté client présentant une vulnérabilité de sécurité connue. La nouvelle version du site HTTP Archive rendra compte de l’évolution de ces chiffres au fil du temps.

Nous pouvons approfondir l’analyse pour voir combien de vulnérabilités connues se trouvent dans ces bibliothèques :

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)

Il s’avère que si un site présente au moins une vulnérabilité connue, il en présente probablement plusieurs. 51,8 % des sites vulnérables en comptent plus d’une. La plupart de ces sites en présentent une ou deux, mais la longue traîne est préoccupante : 9,2 % des sites utilisent des bibliothèques cumulant au moins quatre vulnérabilités de sécurité connues.

Quelles sont les bibliothèques les plus souvent vulnérables ?

Les données d’audit de Lighthouse nous permettent également de déterminer quelles bibliothèques sont le plus souvent reconnues comme vulnérables.

Pour commencer, nous pouvons rechercher les bibliothèques les plus souvent détectées, qu’elles soient vulnérables ou non. La requête suivante récupère les dix bibliothèques les plus fréquemment détectées :

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

Sans surprise, jQuery arrive en tête. Cela correspond tout à fait à ce que nous avions observé en mars et à ce que vous pouviez probablement anticiper. Aucune bibliothèque n’a encore réussi à égaler l’omniprésence de jQuery. À noter toutefois : React est actuellement sous-représenté. Une fois le script de détection mis à jour intégré à Lighthouse, ses chiffres augmenteront (et le pourcentage global de sites vulnérables devrait lui aussi légèrement progresser).

Voyons maintenant quelles bibliothèques sont reconnues comme présentant des vulnérabilités connues.

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

Les premières bibliothèques de la liste sont très similaires.

Les pourcentages ne sont guère réjouissants. En production, 92,5 % des versions de jQuery — de loin la bibliothèque la plus populaire du Web — présentent une vulnérabilité de sécurité connue. En fait, parmi les dix bibliothèques les plus souvent reconnues comme vulnérables, six le sont dans la majorité des versions utilisées en production.

Et ce, alors que chacune des bibliothèques de cette liste propose des versions exemptes de ces vulnérabilités.

Les bibliothèques front-end les plus souvent reconnues comme vulnérables n’ont présenté aucune vulnérabilité connue depuis un à cinq ans. En réalité, les bibliothèques et frameworks front-end ne sont souvent plus mis à jour une fois déployés en production.

Des raisons d’espérer

La situation est plutôt sombre aujourd’hui, impossible de le nier. Ces données ne signifient pas que les 77 % de sites concernés sont tous exploitables (ils peuvent ne pas utiliser les méthodes vulnérables), mais c’est une bien maigre consolation. Sur ces 77 % de sites, il suffit qu’un développeur appelle une méthode pour créer une vulnérabilité. Comme nous l’avons constaté en 2017, les vulnérabilités open source doivent être prises très au sérieux.

Mais il y a aussi une bonne nouvelle. Malgré le grand nombre de vulnérabilités en production, celles-ci ont été corrigées dans les bibliothèques concernées. Toutes les grandes bibliothèques proposent des versions exemptes de vulnérabilités de sécurité connues : il ne reste qu’à les déployer en production.

Pour améliorer la situation, plusieurs changements sont nécessaires. Tout d’abord, il faut de meilleurs outils et une adoption plus large de ces derniers. Selon notre enquête sur l’état de la sécurité de l’open source, 38 % des personnes qui utilisent l’open source n’ont recours à aucun outil automatisé pour maintenir leurs packages à jour. Je serais prêt à parier que ce taux d’adoption serait encore plus faible si l’on se penchait spécifiquement sur l’utilisation de JavaScript front-end.

Ce chiffre devrait s’améliorer. Les améliorations apportées à npm et Yarn ont considérablement simplifié la gestion des packages front-end pour les développeurs. En associant un processus fiable de gestion des packages à des outils comme Snyk, qui vous aident à détecter, prévenir, corriger et surveiller les dépendances de vos packages, vous contribuerez grandement à renforcer la sécurité du Web.

Il faut également mieux faire connaître le problème et le comprendre. C’est pourquoi nous avons publié le rapport sur l’état de la sécurité de l’open source : pour mettre en lumière les défis liés à la sécurisation de l’open source et contribuer à trouver des pistes d’amélioration.

L’audit des bibliothèques vulnérables dans Lighthouse (et Sonar) est également utile. Ces outils permettent aux développeurs de repérer plus facilement les problèmes sur les sites qu’ils créent. Et grâce à HTTP Archive et BigQuery, nous disposons de données facilement accessibles pour mesurer l’ampleur du problème.

Les données actuelles sont certes peu encourageantes, mais une meilleure sensibilisation et de meilleurs outils peuvent permettre de résoudre ce problème à l’avenir.