IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un projet Node.js sur deux audité par les outils de npm aurait au moins une vulnérabilité
Une sur dix d'entre elles est critique

Le , par Stéphane le calme

888PARTAGES

16  0 
npm est désormais incontournable pour les développeurs JavaScript . Apparu avec node.js en 2009 son usage dépasse aujourd’hui l’environnement serveur. Il est de plus en plus utilisé pour des applications front et son usage comme outil de développement devient quasi systématique. De plus il reste simple et permet d’accéder au plus gros dépôt de paquets tous langages confondus.

La nuit du 11 au 12 juillet 2018, un hacker a accédé au compte npm d'un développeur et a injecté du code malveillant dans une bibliothèque JavaScript populaire, un code conçu pour voler les informations d'identification npm des utilisateurs qui utilisent le paquet infecté dans leurs projets. Pour rappel, npm est le gestionnaire de paquets officiel de Node.js.

Quelques mois avant, en mai, l’équipe a découvert une porte dérobée dans un paquet JavaScript populaire ; « getcookies », un paquet npm relativement récent (bibliothèque JavaScript) qui fonctionne avec les cookies du navigateur. L'équipe npm a analysé ce paquet et, dans ses rapports, a indiqué que getcookies contient un système complexe pour recevoir les commandes d'un attaquant distant qui pourrait cibler n'importe quelle application JavaScript qui a incorporé cette bibliothèque. La porte dérobée fonctionnait en analysant les requêtes HTTP request.headers fournies par l'utilisateur à la recherche de données spécifiquement formatées.


Selon l'équipe npm, la porte dérobée « permettait à un attaquant de saisir du code arbitraire sur un serveur en cours d'exécution et de l'exécuter ». Le module backdoor d'origine a été importé dans d'autres paquets. La bibliothèque getcookies était nouvelle et pas très populaire. L'équipe npm a expliqué qu'elle a découvert une chaîne de dépendances imbriquées à travers laquelle le paquet getcookies avait indirectement fait partie de la structure d'une bibliothèque très populaire appelée Mailparser.

Un mois plus tôt, venait la commande audit à la version 6 de la ligne de commande éponyme npm. Par la suite, les développeurs avaient la possibilité de taper npm audit à partir de la ligne de commande dans un répertoire de projet Node.js, générant une liste des vulnérabilités connues affectant les dépendances de paquets issues du code stocké dans le registre NPM.

Mieux encore, il suffirait de taper npm install (la commande pour remplir un projet Node.js avec les paquets déclarés dans le fichier package.json) pour lancer un audit de sécurité automatique.

La remédiation n'est pas automatique, mais depuis mai, les utilisateurs ont eu la possibilité d'utiliser npm audit fix pour remplacer les modules obsolètes et non sécurisés dans les projets avec des projets sécurisés.

Depuis avril, selon les déclarations des responsables, les utilisateurs de npm ont effectué 50 millions d’analyses automatiques et ont délibérément appelé la commande 3,1 millions de fois. Et ils exécutent 3,4 millions d'audits de sécurité par semaine.

Parmi tous les audits, 51% ont identifié au moins une vulnérabilité et 11% ont identifié une vulnérabilité critique.

De nombreuses options pour améliorer la sécurité

Dans un billet de blog, un membre de l’équipe répondant au pseudonyme Adam, a écrit « Comme vous l’avez probablement remarqué, npm a déployé des fonctionnalités de sécurité. Nous avons trois nouvelles fonctionnalités sur le site que nous aimerions partager : un bouton pour rapporter une vulnérabilité, des conseils de sécurité et une fonctionnalité qui empêche l’utilisation de mots de passe compromis ».

Signaler une vulnérabilité

Le nombre croissant de paquets dans le registre npm contraint à avoir une communauté vigilante capable de signaler tout élément suspect. Si vous sentez que vous avez trouvé une faille de sécurité ou un module malveillant dans le registre, il est facile de faire remonter cette information grâce à ce bouton présent sur chaque paquet. Il vous suffira alors de remplir les informations pour passer la main à l’équipe.


Amélioration des avis de sécurité

Les avis de sécurité sont ce qui alimente npm audit. Ils vous donnent un bref aperçu des vulnérabilités d'un paquet, comment l’équipe recommande d’y répondre ainsi que des liens de référence pratiques pour en savoir plus.

« La transition vers Node Security Plateform nous a obligé à déplacer les avis de sécurité vers npmjs.com, nous avons donc saisi cette opportunité pour améliorer leur apparence. Nous avons également ajouté un calendrier détaillé pour les futurs avis afin que vous puissiez apprendre ce qui a changé et quand, au cours du cycle de vie d'un avis », a expliqué Adam.


Blocage de la réutilisation des mots de passe des informations d'identification compromises

Il est assez courant pour les utilisateurs de réutiliser les mots de passe entre les comptes, mais c'est une pratique extrêmement risquée qui devrait être évitée. Si un mot de passe partagé est utilisé sur un autre compte victime d'une violation de données, les attaquants peuvent utiliser ces données publiques pour se frayer un chemin dans le compte npm de l'utilisateur et dans d'autres comptes.

Lorsque vous vous inscrivez à npm ou que vous modifiez votre mot de passe, le hash de votre mot de passe choisi sera comparé à la liste des 571 millions de mots de passe répertoriés dans le projet Have I Been Pwned de Troy Hunt.

Si une correspondance est trouvée, une erreur apparaîtra et vous ne serez pas autorisé à utiliser le mot de passe.

.
Source : blog npm

Et vous ?

Avez-vous des projets nmp ?
Avez-vous déjà utilisé npm audit ? Qu'en pensez-vous ?
Que pensez-vous des nouvelles options pour améliorer la sécurité ?

Voir aussi :

Node.js : eslint-scope, un paquet npm, a été infecté par un hacker, pour lui permettre de voler des identifiants npm
npm : l'authentification à deux facteurs rendue obligatoire en bêta pour les mainteneurs sur les paquets indiqués comme protégés
npm : la version 6.2.0 du gestionnaire de paquets officiel de Node.js passe en @latest, avec quatre nouveautés d'importance autour
npm : un bogue avec le code d'erreur « 418 I'm a teapot » a affecté le registre, empêchant l'utilisation du client npm derrière un proxy
npm : une porte dérobée a été découverte dans le paquet getcookies, qui a des dépendances imbriquées avec le paquet populaire Mailparser

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de blbird
Membre chevronné https://www.developpez.com
Le 27/08/2018 à 16:05
N'importe quel projet peut avoir des problèmes de sécurité, qu'ils se basent sur Node, Django, Java ou DotNet.

Mais attention, NPM est un gestionnaire de paquets pour Node.js, ce n'est pas Node.js. Ce qui déjà n'a rien à voir avec Django...

Mais surtout que Node en lui-même est sécurisé, c'est son utilisation dans leur code par des développeurs qui peut ne pas l'être, comme tout autre Framework, outil ou serveur Web... Ainsi que des modules (librairies) basées sur Node qui peuvent être compromises, comme partout ailleurs.

Le titre de cet article est à mon sens mauvais : il laisse penser que c'est Node le problème, alors que ce n'est pas ça du tout.
3  0 
Avatar de Max Lothaire
Membre confirmé https://www.developpez.com
Le 27/08/2018 à 16:34
Voila pourquoi je préfère un Django à node.js ... ce machin n 'est pas secure
N'importe qui peut publier du code sur PyPI, c'est pas bien différent de NPM.
Le problème c'est la tendance à multiplier les dépendance à des outils tiers sans faire attention à ce quel font.
2  0 
Avatar de fraxken
Candidat au Club https://www.developpez.com
Le 28/08/2018 à 18:13
Bonjour,

Ce qui me fait peur c'est surtout l'ignorance autour d'un sujet aussi important que la sécurité (sans parler du titre et du contenu pute à clic sur un fond aussi important).

Les problèmes de sécurité dans l'Open-source concernent l'intégralité des écosystèmes ( Source: https://snyk.io/stateofossecurity/ ). À l'heure d'aujourd'hui, seul le Working Groupe Node et l'entreprise NPM semble prendre le problème au sérieux et y répondre par des articles et des mises à jour dans l'objectif de faire mûrir l'écosystème (et pourquoi pas un jour inverser les courbes).

L'article omet un point très important sur le fonctionnement de NPM, Il existe plusieurs types de dépendance dans un projet Node:

- Les dépendances normales (qui seront utilisé en production)
- Les dépendances développeurs (uniquement utilisé lors du développement, comme le Linter, Webpack etc...)

La plupart des fails de sécurité ne se trouvent donc pas sur les packages qui sont couramment utilisés en production sur la stack Node. Le reste n'en est pas pour autant moins important (A bonne entendeur). Mais il faut aussi laisser le temps aux mainteneurs et développeurs de corriger et monter en sagesse sur le sujet.

Cordialement,
1  0 
Avatar de
https://www.developpez.com
Le 27/08/2018 à 19:57
Npm n'est pas node et pypi n'est pas python mais bon, ils sont quand même fondamentaux dans leur écosystème. Perso, je trouve ça assez inquiétant.
0  0 
Avatar de blbird
Membre chevronné https://www.developpez.com
Le 28/08/2018 à 11:50
Citation Envoyé par SimonDecoline Voir le message
Npm n'est pas node et pypi n'est pas python mais bon, ils sont quand même fondamentaux dans leur écosystème. Perso, je trouve ça assez inquiétant.
De la même manière que DotNet est fondamental pour du code DotNet open-source... Ce n'est pas DotNet (ou Node) le problème, mais le code des développeurs qui peut-être non-sécurisé. Et s'il est réutilisé, ca démultiplie le problème.
0  0 
Avatar de darklinux
Membre extrêmement actif https://www.developpez.com
Le 29/08/2018 à 5:48
Mais je suis d ' accord , mais la sécurité est encore considéré comme accessoire en 2018 . Hors c 'est critique au possible , cela ne ce discute pas . Je veux bien le coup des APIs faiblarde , pour une implémentation " spécial " . Mais même dans ce cas , cela peut être corrigé avec une conception au cordeau .
0  0 
Avatar de
https://www.developpez.com
Le 31/08/2018 à 18:39
Citation Envoyé par Max Lothaire Voir le message
N'importe qui peut publier du code sur PyPI, c'est pas bien différent de NPM.
Le problème c'est la tendance à multiplier les dépendance à des outils tiers sans faire attention à ce quel font. (surtout quand ces dépendances ne font que quelques lignes)
Javascript n'a pas ce type de fonction en natif ?
0  0 
Avatar de darklinux
Membre extrêmement actif https://www.developpez.com
Le 27/08/2018 à 14:32
Voila pourquoi je préfère un Django à node.js ... ce machin n 'est pas secure
0  4