Les vulnérabilités les plus courantes dans Maven Central et npm

La version intégrale de cet article a d’abord été publiée par Snyk en tant qu’article invité sur le blog de Cloud Foundry.

Dans cet article, nous passons en revue les types de vulnérabilités les plus courants dans deux des principaux écosystèmes que nous suivons dans notre base de données des vulnérabilités : Maven Central et npm. La base de données Snyk Vulnerability Database recense les vulnérabilités de plus de 1 000 000 de packages open source que nous suivons et qui utilisent Composer, Go, Maven Central, npm, NuGet, pip et Rubygems.

En 2017, le nombre de vulnérabilités publiées dans les écosystèmes que nous suivons a atteint un niveau record, avec une hausse de 83 % par rapport à 2016. Nous pouvons voir quels types de vulnérabilités ont été les plus fréquents dans les deux principaux écosystèmes dont nous allons parler ici.

Dans nos articles d’avril et de mai, nous examinerons plus en détail certaines de ces vulnérabilités pour voir comment elles peuvent être exploitées.

JavaScript (npm)

1. Traversée de répertoires – Exemple : le package st.

La vulnérabilité la plus courante dans l’écosystème npm est la traversée de répertoires. Elle survient généralement lorsqu’un chemin de répertoire relatif est fourni sans être validé. En l’absence de validation, le chemin relatif transmis peut pointer vers un répertoire parent et donner accès à des données sensibles. Par exemple, une méthode souvent utilisée pour exploiter cette faille consiste à utiliser des entités HTML, où « . » est représenté par « %2E ». Dans ce cas, une requête vers l’URL suivante, /%2E%2E/%2E%2E/%2E%2E/etc/password, entraîne la divulgation du fichier /etc/passwd.

Téléchargement de ressources via un protocole non sécurisé – Exemple : Chromedriver.

Cette vulnérabilité permet aux attaquants de mener une attaque de l’homme du milieu (MitM). Lorsque des ressources sont téléchargées via un protocole non sécurisé, un attaquant peut intercepter la connexion et modifier les packages reçus.

3. Cross-site scripting (XSS) – Exemple : le package handlebars.

Les attaques XSS surviennent lorsqu’un attaquant incite le navigateur d’un utilisateur à exécuter du code JavaScript malveillant dans l’environnement de la victime. Ces scripts peuvent dérober les cookies de session de l’utilisateur pour le domaine, récupérer les mots de passe ou les numéros de carte bancaire saisis, extraire ou modifier le contenu, et effectuer ou modifier des actions au nom de l’utilisateur. Ces actions seraient normalement bloquées par la politique de même origine du navigateur. Pour en savoir plus, consultez Les attaques XSS, la prochaine vague.

Maven Central

1. Déni de service (DoS) – Exemple : le processeur de données jackson.

Une vulnérabilité de déni de service épuise les ressources des serveurs back-end, ce qui affecte ensuite les requêtes des autres utilisateurs. Cela se produit souvent par une consommation excessive du processeur, mais peut aussi résulter du remplissage des disques, de la mémoire ou d’autres ressources du serveur.

2. Exécution de code arbitraire – Exemple : la bibliothèque Apache Struts.

L’exécution de code arbitraire consiste à exécuter du code malveillant envoyé à un serveur vulnérable. Ce code invoque souvent des commandes sur la machine distante. Elle résulte fréquemment d’une autre vulnérabilité, par exemple une vulnérabilité de désérialisation, comme dans le cas de Struts.

3. Cross-site scripting (XSS) – Exemple : le plug-in Jenkins CI Server.

Consultez la description des attaques XSS dans la section npm ci-dessus.

Pour découvrir d’autres vulnérabilités courantes dans ces écosystèmes, consultez l’article complet sur le blog de Cloud Foundry.