Identifier, hiérarchiser et corriger les vulnérabilités avec Reachable Vulnerabilities pour GitHub

Imaginez que vous êtes programmeur Java et que vous venez de décider d’utiliser l’analyse de Snyk Open Source pour détecter les problèmes de sécurité dans vos bibliothèques tierces. Bonne décision !

Cependant, après avoir connecté votre dépôt à l’outil d’analyse Snyk Open Source, vous découvrez que les packages dont vous dépendez présentent dix, voire 50 vulnérabilités. La grande question est alors : par où commencer ?

Dans un monde idéal, vous corrigeriez toutes les vulnérabilités et n’en laisseriez aucune. Nous savons tous que ce n’est pas toujours faisable. De plus, vous ne pourrez probablement pas toutes les corriger en même temps. Commencez par les problèmes les plus critiques qui ont un impact sur votre application, puis poursuivez la correction des vulnérabilités. Voyons comment procéder.

L’application

J’ai créé une petite application Java basée sur Maven, que j’ai publiée sur GitHub. Elle prend une URL et envoie une requête GET à cette adresse. Le résultat s’affiche en texte brut sur la page de résultats. Il peut s’agir du HTML d’une page web ou, par exemple, de la réponse d’un endpoint REST. J’utilise le client HTTP d’Apache et quelques autres dépendances pour exécuter les requêtes, comme indiqué dans le fichier pom.

<dependencies>
   <dependency>
       <groupId>org.apache.httpcomponents</groupId>
       <artifactId>httpclient</artifactId>
       <version>4.3.1</version>
   </dependency>
   <dependency>
       <groupId>javax.servlet</groupId>
       <artifactId>javax.servlet-api</artifactId>
       <version>3.0.1</version>
       <scope>provided</scope>
   </dependency>
   <dependency>
       <groupId>org.owasp.encoder</groupId>
       <artifactId>encoder</artifactId>
       <version>1.2.2</version>
   </dependency>
   <dependency>
       <groupId>org.yaml</groupId>
       <artifactId>snakeyaml</artifactId>
       <version>1.25</version>
   </dependency>
</dependencies>

Détecter les vulnérabilités de sécurité dans votre dépôt GitHub

Pour détecter les vulnérabilités de sécurité dans mes dépendances open source, j’ai connecté mon dépôt GitHub à Snyk. J’ai également activé la fonctionnalité Reachable Vulnerabilities, actuellement en version bêta. Vous trouverez cette option dans Paramètres -> Intégration -> Modifier les paramètres de GitHub. À noter que tout ce que j’utilise ici est inclus dans l’offre gratuite de Snyk.

Une fois l’analyse de mon dépôt GitHub terminée, Snyk m’indique que mon application présente de nombreuses vulnérabilités héritées du package open source que j’utilise. La fonctionnalité Reachable Vulnerabilities m’indique toutefois si une vulnérabilité est atteignable depuis du code comme celui ci-dessous.

Hiérarchiser la correction des vulnérabilités

La vulnérabilité liée à une validation incorrecte des entrées est un problème de gravité élevée dans la version 4.3.1 de httpclient d’Apache. L’interface Snyk m’indique que la fonction vulnérable est atteignable via la méthode doPost de mon URLServlet. Ce problème précis concerne une entrée URI qui n’est pas validée correctement et qui peut nuire à votre logiciel. Après quelques tests, j’ai découvert au moins un des problèmes.

L’URI peut inclure les identifiants de l’hôte. Par exemple, http://bmv:pwd@snyk.io renvoie au domaine snyk.io. En revanche, si j’ajoute un autre signe @ dans la partie du mot de passe des identifiants, je peux sortir de l’URL. En bref, http://bmv:pwd@foojay.io:80@snyk.io me renvoie le résultat du domaine foojay.io, et non celui de snyk.io.

L’indicateur d’atteignabilité est disponible pour l’intégration GitHub de la plateforme Snyk dans les projets Java Maven. C’est un outil essentiel pour hiérarchiser la correction des vulnérabilités dans votre application. Lorsque cet indicateur est présent, cela signifie qu’il existe un chemin entre votre code et la méthode vulnérable du package importé.

Pour calculer l’atteignabilité dans l’intégration GitHub, Snyk crée une branche de votre code et l’inspecte. Nous créons un graphe d’appels et l’analysons afin de déterminer s’il existe un chemin vers une méthode présentant une vulnérabilité connue. Si c’est le cas, la vulnérabilité concernée reçoit le badge « atteignable ». De plus, le fait qu’une vulnérabilité soit atteignable influe également sur le score de priorité affiché dans le coin supérieur droit. Ce score agrège plusieurs heuristiques pour aider les développeurs à déterminer quelles vulnérabilités sont les plus dangereuses dans leur contexte et doivent donc être traitées en priorité.

En faisant défiler l’interface Snyk vers le bas, je vois d’autres vulnérabilités, notamment un problème de déni de service dans le package snakeyaml. Notez que cette vulnérabilité n’est pas signalée comme atteignable : dans mon exemple de programme, j’importe le package, mais je ne l’utilise jamais.

Conclusion

Reachable Vulnerabilities pour notre intégration GitHub est une fonctionnalité puissante et gratuite qui aide tous nos utilisateurs à mieux décider par où commencer la correction des vulnérabilités et lesquelles traiter en premier.

Cela ne signifie toutefois pas que vous pouvez ignorer sans risque les vulnérabilités qui ne sont pas signalées comme atteignables. Elles font toujours partie de votre application et peuvent être déclenchées d’autres manières.

En Java notamment, il existe des mécanismes comme l’API de réflexion. De plus, toutes les classes sont accessibles via le classpath. Ainsi, si l’exécution de code arbitraire est possible dans votre application, toutes les classes disponibles peuvent être chargées et exploitées.

Ce que je veux dire, c’est que des vulnérabilités qui ne sont pas directement atteignables peuvent tout de même être exploitées au fil d’une chaîne d’événements. Néanmoins, Reachable Vulnerabilities vous aide à savoir par où commencer pour améliorer et sécuriser votre application ! Alors, qu’attendez-vous ? Créez un compte Snyk gratuit et essayez par vous-même !

L’application utilisée dans cet article de blog est disponible dans ce dépôt GitHub.