Yarn est ultra sécurisé

Il y a quelques semaines, Facebook a annoncé la publication de Yarn en open source : un nouveau client pour le registre npm. Quelques personnes ont exprimé des inquiétudes, mais ce projet semble être un bel exemple de développement open source. Facebook, Google, Exponent et Tilde rencontraient des difficultés similaires avec le client npm par défaut. Plutôt que de chercher chacun de leur côté à résoudre le problème, ils se sont réunis et ont fait évoluer npm. Le résultat : un client alternatif qui apporte des améliorations notables sans renoncer à la puissance du registre npm sous-jacent.

Yarn se présente comme « ultra rapide », « super fiable » et « méga sécurisé ». S’il est vrai que Yarn est souvent beaucoup plus rapide et que son nouveau fichier de verrouillage garantit davantage de cohérence lors de l’installation de votre application, les affirmations concernant sa sécurité sont un peu trop optimistes.

Ce que Yarn apporte à la sécurité

Quand Yarn se dit « méga sécurisé », il fait référence à l’utilisation de sommes de contrôle pour vérifier que le paquet demandé est bien celui que vous recevez, sans aucune modification.

Vérification des sommes de contrôle

Vous pouvez le constater en ouvrant le fichier yarn.lock dans l’un de vos projets. En voici un extrait :

moment:
  version "2.15.2"
  resolved "https://registry.yarnpkg.com/moment/-/moment-2.15.2.tgz#1bfdedf6a6e345f322fe956d5df5bd08a8ce84dc"

L’extrait ci-dessus montre que nous avons demandé le paquet moment, et que le paquet a été résolu à l’URL suivante :

https://registry.yarnpkg.com/moment/-/moment-2.15.2.tgz#1bfdedf6a6e345f322fe956d5df5bd08a8ce84dc

La section qui suit le hachage est particulièrement intéressante :

1bfdedf6a6e345f322fe956d5df5bd08a8ce84dc

Il s’agit de la somme de contrôle du fichier, calculée à l’aide de l’algorithme Secure Hash Algorithm 1 (SHA-1). Si vous téléchargez le paquet depuis cette URL sur votre machine, vous pouvez vérifier la somme de contrôle en ligne de commande avec la commande sha1sum sous Linux ou shasum sous Mac OSX.

# On Linux
sha1sum moment-2.15.2.tgz

# On Mac OSX
shasum moment-2.15.2.tgz

Ces commandes affichent le hachage SHA-1, qui correspond à celui indiqué dans le fichier de configuration. Supposons que vous demandiez ce paquet, mais qu’il diffère d’une manière ou d’une autre de ce qu’indique la somme de contrôle dans le fichier yarn.lock. Par exemple, j’ai ajouté une ligne au fichier README.md, recréé l’archive .tgz, puis exécuté à nouveau shasum. Le nouveau hachage était le suivant :

9a6c63c40298234627114c821529a8e42a073f98

Ce nouveau hachage ne correspond pas à celui que vous attendiez : vous pouvez donc constater que quelque chose a changé. Ce que vous avez demandé ne correspond pas à ce que vous avez reçu. Ce quelque chose peut être anodin — une erreur lors du transfert a peut-être corrompu le fichier. Il peut aussi s’agir d’un problème plus malveillant : un attaquant a peut-être récupéré le paquet et l’a manipulé. La somme de contrôle vous signale qu’un problème est survenu afin que vous puissiez mener l’enquête.

Comment les attaquants peuvent-ils altérer un paquet ?

Garantir l’intégrité des données est certes une fonctionnalité appréciable, mais il est légitime de se demander comment un attaquant pourrait manipuler un paquet au départ.

Une possibilité consiste à modifier le paquet à la source, dans le registre qui l’héberge. La plupart des utilisateurs téléchargent leurs paquets depuis npmjs.com, où, à ma connaissance, aucun cas de modification de code par des attaquants au niveau du registre n’a été signalé.

L’autre possibilité consiste à modifier le paquet pendant son téléchargement. Là encore, la plupart des paquets sont téléchargés depuis le registre public npm, qui utilise HTTPS. Il est possible de modifier des paquets en transit via HTTPS, mais c’est loin d’être simple.

Les sommes de contrôle sont plus utiles lorsque vous hébergez votre propre dépôt. Les solutions d’Artifactory et de Nexus sont bien sécurisées, mais si vous créez votre propre solution, certaines failles pourraient permettre de manipuler directement les paquets dans le registre. Et même si nous vous le déconseillons vivement, nous avons vu des registres locaux servis via HTTP. Dans ces situations, il est beaucoup plus facile de modifier les paquets, ce qui rend les sommes de contrôle d’autant plus importantes.

Si vous utilisez le registre public npm ou hébergez le vôtre via HTTPS avec une solution commerciale, les manipulations contre lesquelles les sommes de contrôle vous protègent posent moins de problèmes. C’est une fonctionnalité de sécurité, mais secondaire.

yarn.lock pour figer les versions

De plus, le fichier yarn.lock introduit une complication dans votre stratégie de sécurité. Comme npm shrinkwrap, le fichier yarn.lock sert à verrouiller des versions précises de vos dépendances. L’avantage d’un fichier de verrouillage, c’est que si j’installe un projet Yarn sur ma machine, puis que j’installe la même application dans un environnement de production le lendemain, je sais que les deux installations utiliseront exactement les mêmes dépendances, même si une nouvelle version est sortie entre-temps.

C’est excellent pour la cohérence, mais les fichiers de verrouillage tendent à empêcher la mise à jour des paquets que vous utilisez. Contrairement à l’utilisation des plages semver, la seule façon de passer à une nouvelle version d’une dépendance est de modifier ou de recréer le fichier de verrouillage. Il incombe désormais aux développeurs de surveiller les mises à jour susceptibles de corriger des vulnérabilités critiques, encore plus qu’avec des approches fondées sur semver, comme celles utilisées dans package.json.

Cela ne signifie pas pour autant que vous ne devriez pas utiliser de fichiers de verrouillage. Faites-le si la cohérence est importante pour votre application, mais veillez à mettre en place les processus nécessaires pour examiner activement les paquets vulnérables et les mettre à jour.

Le maillon manquant en matière de sécurité

Les sommes de contrôle ajoutent une couche de sécurité, mais ne garantissent pas que le paquet d’origine que vous cherchez à obtenir est lui-même sécurisé. Dans le monde du développement open source, c’est un problème bien plus important. La plupart des mainteneurs open source ont de bonnes intentions, mais il est rare que la sécurité soit une exigence fondamentale lors de la création de ces paquets. Lorsque nous intégrons ces paquets à nos propres projets, nous le faisons à l’aveugle, sans bien comprendre toutes les dépendances qui en découlent ni les problèmes de sécurité qu’elles peuvent dissimuler.

Par exemple, le paquet moment que nous avons examiné plus tôt comporte une vulnérabilité de déni de service par expression régulière pour laquelle un correctif est disponible. Installer le paquet avec Yarn ne nous en informera pas. L’analyse des dépendances pour détecter les vulnérabilités connues est un problème de sécurité différent, et plus important, que celui auquel Yarn répond.

Comment être vraiment méga sécurisé ?

Heureusement, comme Yarn repose sur npm, il s’intègre plutôt bien à l’écosystème. Yarn présente encore quelques aspérités, mais une fois celles-ci corrigées, les outils de sécurité existants devraient fonctionner avec un minimum de changements.

Par exemple, pour corriger les vulnérabilités connues dans les paquets npm, nous recommandons actuellement d’exécuter snyk protect à l’étape post-install de vos applications Node.js. Si vous exécutez yarn install, cette étape est tout de même déclenchée : snyk protect continue donc de s’exécuter et d’analyser vos dépendances pour détecter les vulnérabilités connues.

Nous trouvons Yarn vraiment génial et, à en juger par l’attention qu’il a reçue, beaucoup semblent être du même avis. Il est généralement plus rapide, et les nouveaux fichiers de verrouillage seront utiles à de nombreuses organisations qui souhaitent rendre leurs installations plus cohérentes.

Mais s’il est formidable de voir Yarn chercher à intégrer la sécurité dès le départ, ses créateurs se montrent un peu trop sûrs d’eux en affirmant que Yarn est « méga sécurisé ». Le problème, ce ne sont pas les sommes de contrôle, c’est le marketing. Elles contribuent à garantir l’intégrité de vos données, mais il s’agit d’un problème relativement secondaire dans l’écosystème Node.js. Il est bien plus essentiel de veiller à ce que ces dépendances soient sécurisées dès le départ.