Share
Les développeurs JavaScript modernes adorent npm. GitHub et le registre npm sont le premier choix du développeur pour trouver un paquet particulier. Les modules open-source contribuent à la productivité et à l'efficacité en fournissant aux développeurs une multitude de fonctionnalités que vous pouvez réutiliser dans votre projet. Il est juste de dire que sans ces paquetages open source, la plupart des frameworks n'existeraient pas dans leur forme actuelle.
Une application d'entreprise à part entière, par exemple, peut s'appuyer sur des centaines, voire des milliers de packages. Les dépendances habituelles incluent les dépendances directes, les dépendances de développement, les dépendances groupées, les dépendances de production et les dépendances facultatives. C'est formidable car tout le monde tire le meilleur parti de l'écosystème open source.
Cependant, l’un des facteurs à négliger est la quantité de risque en cause. Bien que ces modules tiers soient particulièrement utiles dans leur domaine, ils introduisent également des risques de sécurité dans votre application..
Les dépendances du logiciel libre sont en effet vulnérables aux exploits et aux compromis. Voyons quelques exemples:
Une vulnérabilité a été découverte récemment dans un paquet appelé eslint-scope, dépendance de plusieurs paquets JavaScript populaires, tels que babel-eslint et webpack. Le compte du mainteneur du paquet a été compromis et les pirates informatiques y ont ajouté du code malveillant. Heureusement, quelqu'un a découvert l'exploit assez tôt pour que les dégâts soient apparemment limités à quelques utilisateurs..
Moment.js, qui est l’une des bibliothèques les plus utilisées pour analyser et afficher les dates en JavaScript, a récemment révélé une vulnérabilité présentant un indice de gravité de 7,5. L'exploit le rendait vulnérable aux attaques ReDoS. Les correctifs ont été rapidement publiés et ils ont pu résoudre le problème assez rapidement..
Mais ce n'est pas tout. Beaucoup de nouveaux exploits sont découverts chaque semaine. Certains d’entre eux sont divulgués au public, mais d’autres ne font la une des journaux qu’après une infraction grave..
Alors, comment pouvons-nous atténuer ces risques? Dans cet article, je vais vous expliquer certaines des meilleures pratiques standard que vous pouvez utiliser pour sécuriser vos dépendances open source..
Logiquement, lorsque le nombre de dépendances augmente, le risque de se retrouver avec un paquet vulnérable peut également augmenter. Cela est vrai également pour les dépendances directes et indirectes. Bien qu'il n'y ait aucune raison pour que vous cessiez d'utiliser des paquetages open-source, c'est toujours une bonne idée de les suivre..
Ces dépendances sont facilement découvrables et peuvent être aussi simples que d’exécuter npm ls dans le répertoire racine de votre application. Vous pouvez utiliser le -prod argument qui affiche toutes les dépendances de la production et la -longue argument pour un résumé de chaque description de paquet.
En outre, vous pouvez utiliser un service pour automatiser le processus de gestion des dépendances qui offre une surveillance en temps réel et des tests de mise à jour automatiques pour vos dépendances. GreenKeeper, Libraries.io, etc. font partie des outils familiers. Ces outils rassemblent une liste des dépendances que vous utilisez actuellement et suivent les informations pertinentes les concernant..
Avec le temps et les modifications de votre code, il est probable que vous cesserez complètement d’utiliser certains packages et d’en ajouter de nouveaux. Cependant, les développeurs ont tendance à ne pas supprimer les anciens paquets au fur et à mesure.
Au fil du temps, votre projet peut accumuler de nombreuses dépendances inutilisées. Bien qu'il ne s'agisse pas d'un risque de sécurité direct, ces dépendances ajoutent presque certainement à la surface d'attaque de votre projet et génèrent des encombrements inutiles dans le code. Un attaquant peut trouver une faille en chargeant un paquetage ancien, mais installé, ayant un quotient de vulnérabilité plus élevé, augmentant ainsi les dégâts potentiels qu'il peut causer..
Comment vérifiez-vous de telles dépendances inutilisées? Vous pouvez le faire à l'aide de l'outil depcheck. Depcheck scanne tout votre code pour a besoin et importation commandes. Il corrèle ensuite ces commandes avec les packages installés ou ceux mentionnés dans votre package.json et vous fournit un rapport. La commande peut également être modifiée à l'aide de différents indicateurs de commande, ce qui simplifie l'automatisation de la vérification des dépendances inutilisées..
Installez depcheck avec:
npm install -g depcheck
Presque tous les points discutés ci-dessus concernent principalement les problèmes potentiels que vous pourriez rencontrer. Mais qu'en est-il des dépendances que vous utilisez en ce moment?
Selon une étude récente, près de 15% des packages actuels incluent une vulnérabilité connue, que ce soit dans les composants ou les dépendances. Cependant, la bonne nouvelle est qu’il existe de nombreux outils que vous pouvez utiliser pour analyser votre code et détecter les risques de sécurité liés à l’open source au sein de votre projet..
L'outil le plus pratique est npm's audit npm. Audit est un script qui a été publié avec la version 6 de npm. Node Security Platform a initialement développé l'audit npm, puis le registre npm l'a acquis. Si vous êtes curieux de savoir ce qu'est l'audit npm, voici une citation du blog officiel:
Un audit de sécurité est une évaluation des dépendances de paquet pour les vulnérabilités de sécurité. Les audits de sécurité vous aident à protéger les utilisateurs de votre package en vous permettant de rechercher et de corriger les vulnérabilités connues dans les dépendances. La commande npm audit envoie une description des dépendances configurées dans votre package à votre registre par défaut et demande un rapport sur les vulnérabilités connues..
Le rapport généré comprend généralement les détails suivants: le nom du package affecté, la gravité et la description de la vulnérabilité, le chemin d'accès et d'autres informations, ainsi que, le cas échéant, les commandes permettant d'appliquer des correctifs pour résoudre les vulnérabilités. Vous pouvez même obtenir le rapport d'audit en JSON en exécutant npm audit --json.
En dehors de cela, npm propose également une assistance sur la manière d’agir sur la base du rapport. Vous pouvez utiliser correctif d'audit npm pour résoudre les problèmes déjà trouvés. Ces corrections sont généralement effectuées à l'aide de mises à niveau guidées ou de correctifs Open Source..
N'hésitez pas à consulter la documentation de npm pour plus d'informations.
Le concept de sécurité open-source dépend énormément du nombre d'yeux qui surveillent cette bibliothèque. Les paquets activement utilisés sont surveillés de plus près. Par conséquent, il y a plus de chances que le développeur ait résolu tous les problèmes de sécurité connus dans ce package particulier..
Prenons un exemple. Sur GitHub, vous pouvez utiliser de nombreuses implémentations de jetons Web JSON avec votre bibliothèque Node.js. Cependant, ceux qui ne sont pas en développement actif pourraient avoir des vulnérabilités critiques. Une de ces vulnérabilités, rapportée par Auth0, permet à quiconque de créer ses propres jetons "signés" avec la charge utile souhaitée..
Si un paquet raisonnablement populaire ou bien utilisé présentait cette faille, les chances qu'un développeur trouve et corrige la panne seraient plus grandes. Mais qu'en est-il d'un projet inactif / abandonné? Nous en parlerons dans le point suivant.
Le moyen le plus rapide et le plus efficace de déterminer l'activité d'un package spécifique consiste probablement à vérifier son taux de téléchargement sur npm. Vous pouvez trouver cela dans le Statistiques section de la page de package de npm. Il est également possible d'extraire ces chiffres automatiquement à l'aide de l'API npm stats ou en parcourant l'historique des statistiques sur npm-stat.com. Pour les paquetages avec des référentiels GitHub, vous devez consulter l'historique de validation, le suivi des problèmes et toutes les demandes d'extraction pertinentes pour la bibliothèque..
Il existe de nombreux bogues, y compris un grand nombre de bogues de sécurité qui sont continuellement mis à jour et, dans la plupart des cas, immédiatement corrigés. Il n'est pas rare de voir les vulnérabilités récemment signalées corrigées uniquement sur la version / branche la plus récente d'un projet donné..
Par exemple, prenons la vulnérabilité ReDoS (Regular Expression Denial of Service) signalée sur le package HMAC 'faucon' au début de 2016. Ce bogue dans faucon a été rapidement résolu, mais uniquement dans la dernière version majeure, 4.x. Les versions plus anciennes comme 3.x ont été corrigées beaucoup plus tard bien qu'elles soient également exposées au risque.
Par conséquent, en règle générale, vos dépendances sont moins susceptibles d’avoir des problèmes de sécurité si elles utilisent la dernière version disponible..
Le moyen le plus simple de vérifier si vous utilisez la dernière version consiste à utiliser le NPM obsolète commander. Cette commande supporte le -prod drapeau pour ignorer toutes les dépendances dev et --JSON pour simplifier l'automatisation.
Inspectez régulièrement les packages que vous utilisez pour vérifier leur date de modification. Vous pouvez le faire de deux manières: via l’interface utilisateur de npm, ou en exécutant vue npm .
La clé de la sécurisation de votre application est d’avoir dès le départ une culture axée sur la sécurité. Dans cet article, nous avons présenté certaines des pratiques standard pour améliorer la sécurité de vos composants JavaScript..
Accentsconagua
audit npm analyser vos dépendances.Si vous avez des idées sur la sécurité JavaScript, n'hésitez pas à les partager dans les commentaires..
