Sécurité Node.js : enseignements du groupe de travail sur la sécurité de Node.js concernant le triage des vulnérabilités

Dans un précédent article de blog, j’ai parlé d’un signalement de sécurité concernant le framework Node.js Fastify auprès du groupe de travail sur la sécurité de Node.js sur HackerOne. Le signalement portait sur une vulnérabilité d’injection de code JavaScript côté serveur. La conclusion finale a établi que le signalement n’avait aucun impact sur la sécurité du framework d’application web Node.js Fastify, ni de son composant de validation de schéma JSON fast-json-stringify.

Pourquoi un signalement de sécurité ne serait-il pas considéré comme tel ?

Pour répondre à cette question, examinons rapidement les conclusions du signalement et les défis qu’il a posés à l’équipe de réponse aux incidents du groupe de travail sur la sécurité de Node.js.

Le signalement décrivait une attaque par injection de code rendue possible par la manipulation, par un attaquant, d’un fichier JSON utilisé comme schéma pour la validation des requêtes. Une preuve de concept confirmait le problème de sécurité en déclenchant un shell inversé.

Cependant, comme l’a souligné dès le début un responsable de la maintenance de Fastify, il ne s’agissait pas en soi d’un problème de sécurité dans Fastify : cette vulnérabilité de sécurité ne se manifeste pas de façon dynamique et ne résulte pas d’un bug de sécurité dans le code du framework. Le problème survient uniquement lorsque du code non fiable est utilisé comme schéma de validation JSON — généralement écrit par les développeurs eux-mêmes — et non comme source de données issues des utilisateurs.

Ce signalement de vulnérabilité met en lumière plusieurs défis auxquels nous sommes confrontés au sein du groupe de travail sur la sécurité de Node.js, en tant qu’analystes chargés de répondre aux incidents de sécurité :

1. déterminer si un signalement est pertinent et s’il s’agit d’un bug de sécurité

2. identifier la source d’une vulnérabilité

Les problèmes de sécurité Node.js à la limite

À première vue, le problème de sécurité signalé semble être un bug avéré. Après tout, une preuve de concept a été fournie et le scénario d’attaque a été confirmé comme reproductible avec le composant susmentionné.

Cela dit, il faut examiner attentivement non seulement le vecteur d’attaque et les détails de la vulnérabilité, mais aussi l’utilisation prévue du composant concerné. Dans le cas de Fastify, la bibliothèque interdit délibérément l’analyse dynamique du schéma JSON fourni pour valider les requêtes, afin d’atténuer ce type d’attaque par injection de code à l’exécution.

Cela n’empêche toutefois pas les développeurs d’utiliser un schéma d’analyse JSON contenant du code malveillant, comme celui fourni dans la preuve de concept. Mais s’agit-il vraiment d’une vulnérabilité de sécurité ?

C’est là que les choses se compliquent. L’équipe Fastify a clairement indiqué dans la documentation du projet les considérations de sécurité à prendre en compte : les données de configuration du schéma JSON doivent provenir d’une source fiable. Il revient désormais au développeur et à l’équipe qui utilise cette bibliothèque de s’assurer que les données d’entrée sont fiables.

Où se situe la vulnérabilité de sécurité dans Node.js ?

Un autre défi, qui passe souvent inaperçu, consiste à déterminer la source d’une vulnérabilité de sécurité. Dans ce signalement, par exemple, deux composants sont concernés : le framework web Node.js fastify et la bibliothèque d’analyse JSON fast-json-stingify. Lequel faut-il examiner et considérer comme le composant vulnérable dans ce cas ?

D’un côté, fastify ne fait qu’utiliser un autre composant pour analyser le schéma JSON. De l’autre, fast-json-stringify n’a pas pour objectif déclaré de garantir la sécurité face à toutes les entrées possibles et laisse cette responsabilité à l’utilisateur.

Cette difficulté apparaît plus clairement dans un précédent signalement de sécurité, qui illustre bien le problème. Dans ce cas, une vulnérabilité de cross-site scripting (XSS) a été découverte dans une application qui convertit des feuilles de calcul Excel en pages HTML et utilise un composant tiers pour analyser les données des feuilles de calcul. La vulnérabilité XSS affecte l’application elle-même, qui ne nettoie pas les données avant de les afficher dans une page HTML. Elle n’est pas liée au composant tiers, car celui-ci ne peut pas savoir à l’avance si les données d’entrée seront utilisées dans une page HTML ou, par exemple, dans un simple fichier CSV. Par conséquent, cette vulnérabilité ne relève pas du périmètre de la bibliothèque d’analyse des feuilles de calcul Excel.

En résumé

Le triage des vulnérabilités de sécurité exige beaucoup de contexte et d’expérience. Les échanges entre le chercheur en sécurité et le responsable de la maintenance du composant vulnérable sont essentiels pour comprendre dans quelles conditions l’exploitation est possible.

Un autre défi consiste à attribuer correctement un score aux vulnérabilités de sécurité, selon le système commun de notation des vulnérabilités (CVSS). Pour en savoir plus et vous aider à trier les vulnérabilités de sécurité Node.js, j’ai déjà écrit sur les défis liés au CVSS et donné des conseils pour bien l’utiliser.