Fréquence des vulnérabilités connues dans les bibliothèques JavaScript

Un livre blanc intéressant a été présenté la semaine dernière au symposium NDSS. Il présente une étude à grande échelle visant à déterminer à quel point les bibliothèques JavaScript côté client sont vulnérables.

L’étude a consisté à analyser du code JS sur plus de 133 000 sites web. Les chercheurs ont recherché des bibliothèques JavaScript populaires (ils en ont finalement examiné 72), déterminé les versions utilisées, puis vérifié si elles présentaient des vulnérabilités connues. Leurs conclusions sont pour le moins intéressantes.

C’est un excellent rapport, que nous vous recommandons vivement de prendre quelques minutes pour lire. Plusieurs résumés ont déjà été publiés (celui d’Adrian est particulièrement réussi) et nous souhaitions également partager notre point de vue.

Les vulnérabilités connues sont courantes

Les chercheurs ont constaté que 37 % des sites étudiés incluaient au moins une bibliothèque présentant une vulnérabilité connue. Ce chiffre en inquiète beaucoup dans les discussions que nous avons suivies, mais il est probablement bien inférieur à la réalité.

L’étude portait sur les 72 bibliothèques les plus populaires. Elle ne prenait donc pas en compte la longue traîne de bibliothèques moins répandues. Le projet médian que nous surveillons comprend 184 dépendances : la longue traîne du développement JavaScript est considérable. Même si chacune de ces bibliothèques est moins utilisée, leur nombre total est très élevé. Les bibliothèques de cette longue traîne ont aussi tendance à compter moins de contributeurs. Ainsi, lorsqu’une vulnérabilité est découverte, la publication d’une mise à jour corrective peut prendre beaucoup de temps.

La liste des vulnérabilités examinées était également incomplète. Les chercheurs n’ont pas trouvé de base de données des vulnérabilités qui leur convenait et ont donc fait de leur mieux pour en constituer une. Ils ont fait du bon travail, mais il semble que notre base de données contienne au moins quelques vulnérabilités qui n’ont pas été incluses dans leur analyse. Par exemple, bien que la bibliothèque moment figure dans leur liste des bibliothèques populaires, ils ne semblent pas avoir découvert les deux vulnérabilités connues présentes dans de nombreuses versions.

Ils n’ont pas non plus cherché à identifier de nouvelles vulnérabilités, ce qui est tout à fait compréhensible : les découvrir exige beaucoup de temps et d’efforts (notre équipe de recherche pourrait en témoigner). Pourtant, les nouvelles vulnérabilités sont divulguées bien plus souvent que les développeurs ne mettent à jour leurs bibliothèques. Au cours des dix jours qui ont suivi la publication du rapport, nous avons ajouté sept nouvelles vulnérabilités trouvées dans des bibliothèques npm.

En faisant le total, on comprend que si le chiffre de 37 % semblait déjà élevé, la réalité est certainement pire.

Il convient également de rappeler que ces 37 % concernent uniquement le côté client. Notre base de données recense actuellement environ 400 vulnérabilités connues dans des packages npm, et elles ne concernent pas toutes le côté client. Étendre l’étude à l’ensemble de l’écosystème JavaScript donnerait un tableau encore plus préoccupant.

La mise à niveau des bibliothèques est un processus lent

Sur les sites étudiés, la version médiane des bibliothèques utilisées avait 1 177 jours de retard (soit plus de trois ans !) sur la dernière version.

L’adoption tardive des nouvelles versions de logiciels et de bibliothèques n’est pas un problème nouveau, ni propre à l’écosystème JavaScript. Prenez n’importe quelle mise à jour de système d’exploitation : vous constaterez qu’il faut du temps à la plupart des utilisateurs pour l’installer. Et ces systèmes ont généralement l’avantage de pouvoir envoyer directement des notifications de mise à jour à l’ordinateur.

Les bibliothèques JavaScript présentent les mêmes enjeux de sécurité qu’un système d’exploitation, mais sans la possibilité de déclencher directement les mises à jour et avec davantage d’interventions manuelles.

Mettre à jour une bibliothèque demande du temps et comporte des risques. Il faut d’abord découvrir qu’une nouvelle version est disponible, la télécharger, la tester et éventuellement modifier la façon dont vous utilisez la bibliothèque. Si la mise à niveau n’apporte que des changements mineurs et ne modifie pas sensiblement les fonctionnalités, l’effort requis est moindre, mais l’envie de procéder à la mise à jour l’est aussi pour beaucoup.

Une gestion rigoureuse des versions selon semver peut indiquer la complexité d’une mise à niveau, mais rien ne permet vraiment d’évaluer l’urgence d’une mise à jour. Comme l’explique l’article, les correctifs de vulnérabilités ne sont pas toujours clairement signalés dans les notes de version d’une bibliothèque. Pour évaluer l’urgence d’une version, vous devez surveiller les vulnérabilités connues dans vos bibliothèques, ce que la grande majorité des développeurs ne fait toujours pas.

Garder espoir

Les conclusions de l’article sont un douloureux signal d’alarme. De manière générale, notre secteur a rapidement tiré parti de la richesse des ressources offertes par le développement open source, mais il a beaucoup plus tardé à reconnaître les risques associés et à s’en protéger.

À première vue, ces conclusions peuvent sembler décourageantes (les auteurs de l’article l’étaient certainement face à leurs observations), mais nous restons optimistes. Ces derniers temps, la sensibilisation à l’importance de la sécurité progresse lentement. Des normes web plus strictes et plus intelligentes ont été élaborées pour ajouter des couches de sécurité. Les outils s’améliorent également. Il est tout à fait possible de surveiller vos applications JavaScript afin de détecter les problèmes connus, avec des outils adaptés aux développeurs, et de recevoir une alerte lorsque des mises à jour importantes sont publiées.

Il nous reste beaucoup de chemin à parcourir, c’est vrai, mais sécuriser JavaScript est un problème auquel nous pouvons trouver une solution.