Configuration Java : comment prévenir les erreurs de configuration de sécurité
26 février 2021
0 minutes de lectureLa configuration Java est omniprésente. Avec tous les frameworks applicatifs de l’écosystème Java, il est facile de négliger une configuration appropriée. Pourtant, une configuration Java incorrecte peut aussi entraîner un problème de sécurité. C’est ce que l’on appelle une erreur de configuration. Les erreurs de configuration de sécurité figurent dans la célèbre liste des 10 principales vulnérabilités de l’OWASP, à la 6e place.
Une configuration incorrecte de votre application Java peut entraîner des problèmes de sécurité. Tout d’abord, les paramètres par défaut peuvent sembler pratiques, car ils permettent d’utiliser immédiatement une bibliothèque ou un framework. Pourtant, ils ne constituent pas toujours la configuration Java la plus sûre : ils peuvent divulguer des informations utiles au débogage, mais aussi intéressantes pour les intrus.
Problèmes de configuration Java
L’un des exemples les plus connus concerne la mauvaise configuration des analyseurs XML en Java. Dans notre
antisèche 10 bonnes pratiques de sécurité Java, nous avons déjà évoqué le risque d’attaques XXE lié à une mauvaise configuration. J’ai également expliqué dans cette vidéo YouTube que la configuration Java par défaut de tous les analyseurs XML est vulnérable. En appliquant simplement la configuration adéquate et en désactivant les entités externes, nous prévenons les éventuelles attaques XXE.
La configuration de la gestion des erreurs est un autre exemple. Quelle que soit la qualité de votre application web Java, une exception finira tôt ou tard par se produire. Si une exception n’est pas interceptée — et donc pas traitée, par exemple dans une application JSP — le comportement par défaut consiste à afficher l’exception et la trace de pile dans le navigateur.
Cela révèle non seulement que vous utilisez Java, mais aussi le type de package interne auquel vous faites appel. Dans bien des cas, ces exceptions peuvent également contenir des informations précises, comme des identifiants. Aucune de ces informations n’est utile à l’utilisateur et elles nuisent même à son expérience. Plus important encore, elles exposent des informations qui pourraient intéresser des personnes mal intentionnées utilisant votre application.
En configurant des pages d’erreur, comme illustré ci-dessous, vous redirigez l’utilisateur en fonction d’un code de retour ou d’un type d’exception, sans afficher d’informations internes.
Problèmes de configuration des bibliothèques et frameworks Java
Faire appel à des bibliothèques Java et à des packages tiers pour vous décharger d’une partie du travail est une excellente approche. Toutefois, n’oubliez pas que la configuration adéquate de ces outils est essentielle à votre stratégie de sécurité. Heureusement, la plupart des responsables de bibliothèques veillent à ce que les valeurs par défaut soient parfaitement sûres. Les modifier peut sembler pratique, mais vous exposer à de sérieux problèmes.
Prenons Jackson, par exemple : cette bibliothèque bien connue est largement utilisée pour analyser du JSON et le convertir en POJO, et inversement. Si Jackson est mal configuré et que le « typage par défaut » est autorisé, il est possible de désérialiser des objets arbitraires disponibles dans le classpath. Cela peut entraîner le même type de vulnérabilités de désérialisation que celles qui existaient dans la sérialisation native de Java.
Heureusement, cette fonctionnalité est désactivée par défaut, ce qui réduit considérablement le risque d’un problème de désérialisation, pouvant par exemple entraîner l’exécution de code. Toutefois, si vous modifiez cette configuration dans votre application Java et activez cette fonctionnalité, vous risquez d’introduire des problèmes de sécurité indésirables.
Problèmes de configuration de Spring
Spring Framework est le framework de développement d’applications Java le plus populaire. Sa principale fonctionnalité est l’injection de dépendances, ou l’inversion de contrôle.
Spring Boot est essentiellement une extension de Spring Framework. Il permet de créer une application autonome avec peu ou pas de configuration. Spring Boot propose plusieurs composants de démarrage qui ajoutent des fonctionnalités par simple importation de la dépendance adéquate.
Spring Boot Actuator
En ajoutant la dépendance spring-boot-starter-actuator à votre manifeste, Spring Boot Actuator met à votre disposition plusieurs points de terminaison utiles aux responsables de la maintenance et aux développeurs.
On peut citer le point de terminaison env, qui affiche les propriétés de l’environnement, par exemple le contenu du classpath et les beans (tous les beans Spring de l’application), le point de terminaison threaddump, ainsi que shutdown. Consultez la documentation pour voir la liste complète.
Par défaut, tous ces points de terminaison sont activés, mais heureusement, ils ne sont pas tous exposés via HTTP. Il est toutefois facile de configurer ces points de terminaison par défaut et de les activer pour le web ou JMX. Il est également facile de les désactiver avant le passage en production. La ligne suivante dans vos propriétés expose tous les points de terminaison sur le web (à l’exception du point de terminaison shutdown) :
Veillez à n’activer et à n’exposer en production que les points de terminaison dont vous avez réellement besoin. Dans l’idéal, bloquez-les tous, à l’exception de quelques-uns, plutôt que de procéder à l’inverse.
Veillez également à ce que seuls les systèmes et les personnes autorisés puissent accéder aux points de terminaison, en intégrant et en configurant correctement spring-security pour ceux-ci.
Outils de développement Spring Boot
Comme son nom l’indique, ce composant Spring Boot est un ensemble d’outils supplémentaires qui facilite le développement et améliore l’expérience de création d’applications. Des fonctionnalités comme le redémarrage automatique, le débogage à distance et la mise à jour à distance sont particulièrement utiles pendant le développement.
Selon la documentation Spring, le comportement par défaut est le suivant : « Les outils de développement sont automatiquement désactivés lors de l’exécution d’une application entièrement empaquetée. Si votre application est lancée avec java -jar ou démarrée à partir d’un chargeur de classes spécial, elle est considérée comme une “application de production”.
Toutefois, en définissant la propriété `spring.devtools.restart.enabled`, vous pouvez remplacer ce comportement sûr par défaut.
Conclusion
De manière générale, la configuration de votre application Java est tout aussi importante que le code lui-même. Lorsque vous utilisez des frameworks et des bibliothèques, vous devez connaître leurs paramètres de configuration par défaut et savoir si certaines modifications peuvent avoir des conséquences sur la sécurité.
En divulguer trop, que ce soit en laissant la journalisation de débogage activée ou en autorisant des points de terminaison ou des fonctionnalités prévus pour le développement, peut nuire à votre application et à votre entreprise.
Cela vaut pour les frameworks applicatifs et les bibliothèques, mais aussi pour les paramètres de votre serveur web. N’oubliez pas qu’exposer des informations peut sembler inoffensif au premier abord, mais qu’en les combinant, vous pourriez fournir à un attaquant suffisamment d’éléments pour mener une action potentiellement malveillante.
Les bibliothèques, les frameworks et même les serveurs d’applications sont très utiles, mais vous devez comprendre leur fonctionnement. La configuration Java et ses erreurs sont à prendre au sérieux. Veillez à ne pas donner accidentellement accès à votre application parce que vous avez oublié de définir une propriété dans votre configuration.
