Résoudre les problèmes de sécurité Java dans mon application Spring MVC

Spring MVC est un framework Java bien connu pour créer des applications web interactives. Il met en œuvre le modèle d’architecture Modèle-Vue-Contrôleur afin de séparer les différents aspects de votre application. Séparer les différents éléments logiques, comme la logique de présentation, la logique de saisie et la logique métier, est généralement considéré comme une bonne pratique architecturale. Cette séparation des responsabilités, lorsqu’elle est correctement mise en œuvre, vous apporte notamment une réduction de la duplication du code et la possibilité d’utiliser plusieurs vues pour un même modèle.

Spring MVC fait partie du framework Spring et se concentre sur la création d’applications web Java. Il peut s’agir d’une application autonome utilisant un serveur web distinct, comme Tomcat, ou d’une application Spring Boot.

Pour cet article, j’ai créé une application Spring MVC avec des pages web JSP (Java Server Pages) qui s’exécute sur un serveur Tomcat. Le code que j’ai écrit est très simple et direct. Même s’il fonctionne parfaitement, j’ai commis quelques erreurs liées à la sécurité. Voyons comment détecter ces erreurs dans mon application Spring MVC grâce à l’analyse statique du code Java, et comment les corriger.

Mon application Java Spring MVC

L’application Java Spring MVC que j’ai créée est très simple. Il s’agit d’une application basée sur Java 11, qui utilise une version récente de spring-web-mvc. Elle respecte le modèle Modèle-Vue-Contrôleur et interagit avec l’utilisateur au moyen de pages JSP simples. Vous trouverez cette application d’exemple sur GitHub et pouvez l’exécuter avec mvn tomcat7:run.

L’application propose les fonctionnalités de base suivantes :

• Téléverser un fichier dans un dossier

• Téléverser et décompresser un fichier

• Afficher la liste des fichiers téléversés

• Publier un message sur le tableau de messages

• Afficher tous les messages

• Rechercher un message précis.

J’ai limité les dépendances au strict minimum. Même si j’aurais pu utiliser des bibliothèques connues pour prendre en charge les tâches complexes, j’ai écrit toute la logique métier moi-même. En plus de springweb-mvc, j’utilise :

• commons-fileupload pour téléverser les fichiers

• jstl pour la logique de mes fichiers JSP

• h2, une base de données en mémoire pour les messages.

Je sais que cette application contient quelques erreurs de sécurité dans le code. Essayons le tout nouveau Snyk Code et voyons dans quelle mesure l’analyse statique du code Java peut détecter les vulnérabilités que j’y ai introduites.

Snyk Code : outil d’analyse statique du code Java

Snyk Code est un nouveau produit Snyk qui détecte les constructions de code vulnérables dans plusieurs langages, dont Java. L’analyse du code Java de Snyk Code prend également en charge les principaux frameworks, comme Spring MVC, que j’utilise ici. Snyk Code est un outil de test de sécurité des applications statique (SAST). Même si le terme SAST est surtout utilisé dans le monde de la sécurité des systèmes d’information, il décrit exactement ce que fait l’outil : il analyse votre code Java de manière statique pour y repérer d’éventuelles vulnérabilités. Snyk Code s’appuie sur le machine learning pour détecter les vulnérabilités de votre code très rapidement, dans une approche adaptée aux développeurs. Pour cet article, nous allons utiliser l’intégration GitHub avec Snyk afin de tirer parti de Snyk Code.

Remarque : j’utilise actuellement une version en accès anticipé de Snyk Code. La disponibilité générale est prévue en avril.

Analyser mon application Java Spring MVC avec Snyk Code

J’ai activé Snyk Code dans les paramètres de mon compte Snyk. Une fois l’activation terminée, sachez que chaque dépôt que vous importerez par la suite sera analysé par Snyk Code. Cela signifie également que j’autorise Snyk à inspecter activement mon code. Ce n’est pas nécessaire si vous utilisez uniquement Snyk Open Source pour rechercher des dépendances vulnérables. Dans ce cas, il suffit de lire le fichier manifeste, comme pom.xml ou build.gradle.

Après avoir importé le dépôt GitHub contenant mon application Java Spring MVC, je constate presque immédiatement que Snyk Code a fait son travail : l’analyse du code Java a détecté des problèmes de sécurité.

L’outil a détecté plusieurs vulnérabilités de traversée de chemin liées à la logique de téléversement de fichiers. Snyk Code a également repéré plusieurs vulnérabilités d’injection SQL, quelques problèmes de cookies et des identifiants codés en dur. Voyons-en rapidement quelques-unes.

Vulnérabilité de traversée de chemin lors du téléversement de fichiers

Lors du téléversement d’un fichier dans mon application Spring MVC, Snyk Code a détecté que je ne nettoyais pas les fichiers reçus. En écrivant aveuglément le fichier sur le système de fichiers sans le vérifier, je rends possible une traversée de chemin. Un attaquant peut créer une requête POST dont le nom de fichier est interprété comme ../../../../../dir/file.x : il sort alors du répertoire initial et écrit le fichier en dehors de l’application. Il peut également écraser un fichier existant.

Vulnérabilité Zip Slip de traversée de chemin

Un problème similaire de traversée de chemin apparaît lors du téléversement et de la décompression de fichiers ZIP dans mon application Spring MVC. Je crée les fichiers sur le système de fichiers en utilisant les noms contenus dans l’archive ZIP sans les nettoyer. Avec une archive ZIP comme celle ci-dessous, vous pouvez créer ou écraser des fichiers en dehors du périmètre de l’application.

1-rw-r--r--  18-Apr-15 23:04 good.txt
2-rwxrwxrwx  18-Jun-03 17:06 ../../../../../../../../../../../../dir/file.x

Cette vulnérabilité particulière de traversée de chemin dans une archive ZIP s’appelle une vulnérabilité zip-slip. Par le passé, de nombreuses bibliothèques de compression et décompression ZIP présentaient ce type de faille. Pensez donc à analyser vos dépendances avec Snyk Open Source pour détecter ces bibliothèques vulnérables.

Vulnérabilité d’injection SQL lors de la recherche de messages

Dans le dépôt de messages que j’ai écrit pour cette application Java Spring MVC, je crée manuellement la requête de recherche à partir du paramètre fourni. Comme vous pouvez le voir dans la capture d’écran ci-dessous, je n’utilise pas de requête paramétrée. Le paramétrage des requêtes permet de séparer les paramètres de la chaîne de requête proprement dite. Vous pouvez valider et nettoyer les paramètres en les associant, par exemple, à un type précis. Pour l’instant, je concatène simplement le paramètre à la requête existante et je l’exécute. Cela me permet de détourner la requête SQL.

Essayez le paramètre de recherche suivant : '; UPDATE message SET text = 'EVIL. Je sors de la requête d’origine et lance une nouvelle instruction qui met à jour tous les messages. Ce n’est probablement pas ce que vous souhaitez, et heureusement, Snyk Code nous a aidés à détecter cette vulnérabilité.

Autres vulnérabilités détectées par l’analyse du code Java

Snyk a également détecté d’autres problèmes susceptibles de présenter un risque. Par exemple, les propriétés de connexion à ma base de données, notamment le nom d’utilisateur et le mot de passe, sont codées en dur dans mon dépôt. Snyk Code m’a conseillé de ne pas procéder ainsi, à juste titre.

Snyk Code a également repéré un problème lié à un cookie que je définis. Comme il s’agit d’une application web Spring MVC, j’enregistre un cookie pratique sur le système du client pour stocker l’identifiant utilisateur. Cependant, sa durée de vie maximale est fixée à un an. Si vous stockez des informations sensibles dans un cookie, il est déconseillé de définir une valeur élevée pour maxAge. Lorsque vous utilisez des cookies pour stocker temporairement des données, ils ne devraient être valides que pendant une durée limitée. Snyk Code me le signale à juste titre.

Conclusion

Même lors de la création d’une application web Java très simple avec Spring MVC, bien des problèmes peuvent survenir. Notez que je n’ai pas abordé tous les problèmes détectés par Snyk Code dans cette application de démonstration. Je vous laisse les découvrir par vous-même.

Si vous écrivez toute la logique métier vous-même, des problèmes de sécurité peuvent s’y glisser. Sachez qu’il existe des bibliothèques bien maintenues qui vous aident à atteindre le même objectif. Dans l’écosystème Spring, les bibliothèques spring-data en sont un excellent exemple : elles peuvent vous aider à interroger votre base de données. Lorsque vous utilisez des bibliothèques externes, pensez à les analyser avec Snyk Open Source pour éviter d’intégrer une bibliothèque vulnérable. Malgré tout, il est facile d’introduire des problèmes de sécurité dans votre propre code Java, et cela peut arriver à tout le monde. Repérer ces vulnérabilités lors d’une revue de code est difficile. Heureusement, un excellent outil d’analyse statique du code Java comme Snyk Code peut vous aider.