Présentation des politiques d’intégrité expérimentales de Node.js

Une fonctionnalité expérimentale récente permettant de définir des politiques d’intégrité a été intégrée au cœur de Node.js 11.8.0. Disponible pour l’instant dans une version qui n’est pas LTS, cette fonctionnalité vérifie l’intégrité du runtime Node.js au chargement des modules afin de s’assurer que leur code n’a pas été altéré.

Bradley Farias a introduit cette modification en octobre 2018, en s’inspirant d’une fonctionnalité de sécurité similaire utilisée dans les navigateurs : Subresource Integrity.

Subresource Integrity

Le World Wide Web Consortium (W3C) a proposé un nouveau champ integrity dans la spécification HTML, qui permet de vérifier les sous-ressources d’un document HTML. Les pages Web peuvent demander au navigateur de charger des ressources à l’aide d’une balise script ou link. Toutefois, si aucun champ integrity n’est utilisé dans ces éléments HTML, il est impossible de vérifier si une ressource a été altérée.

Les pages Web chargent leurs propres ressources ou celles de tiers depuis des serveurs distants, le plus souvent via un réseau de diffusion de contenu (CDN). Lors du chargement de ces ressources, vérifier l’intégrité des fichiers permet de se protéger contre les acteurs malveillants. Voici quelques exemples :

• Un serveur distant compromis qui pourrait fournir des copies modifiées du fichier de ressource

• Un moyen de transport compromis et son fichier de ressource

Politiques d’intégrité pour les modules Node.js

En nous inspirant du mécanisme de sécurité des navigateurs qui garantit l’intégrité des ressources, imaginons que Node.js puisse faire de même pour les modules tiers : les vérifier avant leur chargement en mémoire et leur exécution lorsqu’ils sont requis par le code du programme.

La nouvelle fonctionnalité expérimentale de politiques de Node.js 11.8.0 permet d’imposer ce comportement à l’aide de l’option de ligne de commande --experimental-policy, qui nécessite un manifeste de politiques répertoriant toutes les ressources d’un projet. Voyons comment cela fonctionne !

Un manifeste de politiques Node.js

La version 11.8.0 applique uniquement les politiques au chargement des modules, mais Node.js ne sait pas encore gérer le manifeste de politiques. Pour gérer le fichier de politiques, nous pouvons utiliser l’outil node-policy CLI de Bradley :

1npm install -g @bradleymeck/node-policy

En exécutant la commande integrity:add de node-policy, nous pouvons créer un manifeste de politiques contenant les empreintes cryptographiques de tous les fichiers du répertoire actuel. Cela inclut tout, du répertoire .git/ à l’ensemble du contenu de node_modules/ ; la génération peut donc prendre un peu de temps.

Pour illustrer son fonctionnement, nous allons l’utiliser avec un module Node.js CLI que j’ai créé pour m’aider à exporter les réponses à des enquêtes typeform.

Exécutez node-policy pour créer un fichier manifeste d’intégrité pour tous les fichiers du répertoire actuel (indiqué par le dernier argument, le point), puis précisez l’algorithme de hachage cryptographique à utiliser. Vous avez le choix entre sha256, sha384 et sha512, conformément à la spécification HTML Subresource Integrity.

Le fichier de politiques généré pour le projet est enregistré dans le répertoire personnel de l’utilisateur. Voici un extrait de .node-policy.json qui illustre la structure du manifeste, avec les URL des fichiers et leurs empreintes d’intégrité :

1"resources": {
2    "./projects/repos/typeform-export-excel/.git/COMMIT_EDITMSG": {
3      "integrity": "sha256-dMEh66Uy32Nr8wO5fy3FAEsZjTeqpBghe9o48gYgZfM="
4    },
5    "./projects/repos/typeform-export-excel/.git/FETCH_HEAD": {
6      "integrity": "sha256-NsU93Hbe+fB2KxZIzQnA299sQRl/4Fg1wk9M0FSYe7E="
7    },
8    "./projects/repos/typeform-export-excel/node_modules/zip-stream/index.js": {
9      "integrity": "sha256-JUKnwX/rS+DRZ0tEQjTl4B/qb3/z7DRMqYiPy9EJpOg="
10    },
11    "./projects/repos/typeform-export-excel/package.json": {
12      "integrity": "sha256-8YN17NVVfPPW+CWsQ2j5LF9MbcnTu6ny/MFkVj/pXjI="
13    },
14    "./projects/repos/typeform-export-excel/src/constants.js": {
15      "integrity": "sha256-wGKtyPIeYuAc0D5L7SrPeiXOqvZYNgqJLkxi8aA/OiQ="
16    },
17    "./projects/repos/typeform-export-excel/src/index.js": {
18      "integrity": "sha256-eJnVeGBKu6vVMHPVS2PKpK6/adC6YLiAEyoIqQwwOjI="
19    }

Si nous exécutons node-policy CLI dans d’autres répertoires de projet, davantage de fichiers seront ajoutés à ce manifeste de politiques. Il s’agit du fonctionnement propre à node-policy, et non d’une spécification ou d’une recommandation.

Pourquoi node-policy crée-t-il le fichier de politiques dans le répertoire personnel de l’utilisateur ? Les bonnes pratiques complètes pour les politiques d’intégrité n’ont pas encore été standardisées. Cependant, puisque ce fichier constitue la source de référence des ressources fiables, mieux vaut le protéger contre toute manipulation. Quelques bonnes pratiques : définissez le fichier en lecture seule et placez-le en dehors de tout répertoire potentiellement accessible.

Pour simuler l’altération d’un fichier et montrer comment Node.js détecte le problème, j’ai apporté une petite modification au code de bin/cli.js, qui fait partie du projet CLI. Lorsque Node.js exécute le code JavaScript de l’exécutable CLI, il détecte que l’empreinte a changé avant de charger ce module CommonJS, puis renvoie une erreur qui ramène Node.js à l’invite de commande.

L’implémentation actuelle permet de consigner les incohérences d’intégrité au lieu de générer une erreur ou de quitter le programme. Pour cela, il suffit d’ajouter une propriété onerror à l’objet de niveau supérieur du fichier manifeste de politiques.

En résumé

Les efforts continus déployés pour intégrer des fonctionnalités de sécurité à Node.js sont prometteurs, et nous en verrons certainement d’autres dans un avenir proche. N’oubliez pas que la fonctionnalité de politique d’intégrité est encore expérimentale et qu’elle n’est disponible qu’à partir de Node.js 11.8.0.