Test d'intrusion Spring Boot : Spring4Shell, Log4Shell, Actuator et Sécurité Java Enterprise
Spring Boot est le framework Java enterprise dominant, mais son histoire récente est marquée par les vulnérabilités les plus médiatisées de la décennie : Log4Shell (CVE-2021-44228) et Spring4Shell (CVE-2022-22965). Au-delà de ces incidents majeurs, les applications Spring Boot exposent régulièrement des endpoints Actuator non sécurisés (/actuator/heapdump, /actuator/env, /actuator/jolokia) qui leakent des secrets ou permettent une RCE directe. Matproof Sentinel effectue un pentest Spring Boot ciblé sur ces classes de vulnérabilités, avec preuve d'exploitation et rapport audit-ready DORA / NIS2 / ISO 27001.
Pourquoi Spring Boot exige une attention pentest exceptionnelle
Spring Boot domine le développement backend Java enterprise depuis 2015. Cette popularité massive a fait de chaque vulnérabilité Spring un événement de sécurité mondial. Log4Shell (CVE-2021-44228, décembre 2021, CVSS 10.0) a affecté littéralement des centaines de millions de serveurs Java exposés ; trois ans après sa découverte, Cisco Talos rapporte que 31 % des serveurs Java scannés en 2024 restent vulnérables. Spring4Shell (CVE-2022-22965, mars 2022, CVSS 9.8) exploite un défaut dans Spring Framework permettant une RCE à distance via la manipulation d'attributs de classe ; la version 5.3.18 a patché le défaut mais des milliers d'applications restent vulnérables. CVE-2023-20861 et CVE-2024-22243 ont continué à exposer Spring à des failles Expression Language (SpEL) injection et URI parsing. Au-delà des CVEs majeures, les déploiements Spring Boot exposent fréquemment des endpoints Actuator en production sans authentification — /actuator/heapdump permet de dumper toute la mémoire JVM (incluant secrets), /actuator/env révèle les variables d'environnement, /actuator/jolokia permet l'exécution de méthodes JMX arbitraires. Un pentest Spring Boot professionnel doit couvrir ces classes de vulnérabilités spécifiques au-delà de l'OWASP Top 10 générique.
- CVE-2021-44228 (Log4Shell, CVSS 10.0) : RCE par injection JNDI dans Log4j 2.x — affecte virtuellement toutes les applications Spring Boot non patchées ; 31 % des serveurs Java scannés en 2024 restent vulnérables (Cisco Talos).
- CVE-2022-22965 (Spring4Shell, CVSS 9.8) : RCE via manipulation d'attributs de classe dans Spring Framework < 5.3.18 / < 5.2.20 — découverte mars 2022, exploit public disponible.
- CVE-2023-20861 (SpEL DoS, CVSS 5.3) : déni de service via expressions SpEL malformées dans Spring Expression — affecte Spring 5.2.x à 5.3.25 / 6.0.x à 6.0.6.
- CVE-2024-22243 (UriComponentsBuilder, CVSS 8.1) : SSRF via mauvaise gestion des URIs dans UriComponentsBuilder de Spring Framework — utilisé dans la majorité des clients HTTP Spring.
- Endpoints Actuator exposés : /actuator/heapdump (dump mémoire JVM incluant secrets), /actuator/env (variables d'environnement), /actuator/jolokia (exécution JMX arbitraire) — Veracode rapporte 18 % des applications Spring Boot scannées en 2024 exposent Actuator sans authentification.
- Désérialisation Java native : ObjectInputStream, XStream, Jackson polymorphic typing — chaîne d'exploitation classique vers RCE via gadgets ysoserial (CommonsCollections, Spring1, etc.).
- Spring Security misconfigurations : règles d'autorisation contournables, CSRF désactivé en production (anti-pattern courant pour API REST), session fixation, JWT signé avec algorithme « none ».
Ce que nous testons spécifiquement dans une application Spring Boot
- Détection Log4Shell active : tests JNDI injection sur tous les champs utilisateur (headers HTTP, paramètres URL, corps de requête JSON) ; détection de versions Log4j vulnérables (1.x EOL et 2.x < 2.17.1) via JAR fingerprinting.
- Spring4Shell exploitabilité : POST avec class.module.classLoader.* payload pour déclencher la RCE ; détection de versions Spring Framework < 5.3.18 / < 5.2.20.
- Endpoints Actuator : énumération des endpoints exposés (/actuator/*), vérification d'authentification, exploitation de /heapdump pour secret extraction, /env pour configuration disclosure, /jolokia pour exécution de méthodes JMX arbitraires.
- Spring Expression Language (SpEL) injection : tests dans tous les champs où SpEL pourrait être évalué (Spring Boot Actuator, @Value expressions exposées à l'utilisateur, Spring Data Repository @Query avec SpEL).
- Désérialisation Java : identification d'endpoints acceptant des objets sérialisés (Java native, XStream, Jackson @JsonTypeInfo) ; tests avec gadgets ysoserial pour démonstration d'exploitation.
- Spring Security configuration : audit du SecurityFilterChain pour règles permettant le contournement d'authentification, CSRF status, configuration JWT (algorithme, validation, expiration), CORS misconfigurations.
- Mass assignment via Spring MVC binding : exposition de champs internes via @ModelAttribute, manipulation d'objets DTO pour escalader les privilèges (changement de role / isAdmin / userId via binding non restrictif).
- Spring Data SQL injection : utilisation de @Query avec concaténation de paramètres utilisateur, NativeQuery sans paramétrage, JPQL injection via Specification dynamique.
- Exposition de fichiers sensibles : application.properties / application.yml exposés via /actuator/configprops ou /actuator/env, secrets en clair dans les configurations.
- JVM-level vulnerabilities : tests de versions Java EOL (Java 8 < 8u391, Java 11 < 11.0.21, Java 17 < 17.0.9) avec CVEs JDK exploitables ; configuration JVM exposant des risques (RMI activé, JMX sans authentification).
Exemple de finding
Endpoint Actuator /heapdump exposé sans authentification — extraction de secrets JVM
L'application Spring Boot expose /actuator/heapdump sans authentification ni restriction d'IP. Un attaquant peut télécharger un dump complet de la heap JVM (typiquement 500 Mo à 4 Go) contenant l'intégralité de l'état mémoire de l'application. Notre test a permis l'extraction de : (1) mots de passe en clair présents en mémoire après authentification d'utilisateurs ; (2) clés API Stripe et AWS conservées en variables Spring Environment ; (3) tokens JWT actifs de sessions en cours ; (4) connexions DB pool avec credentials. L'exploitation est triviale : curl -O https://target.example.com/actuator/heapdump puis analyse avec Eclipse MAT ou jhat. La fenêtre d'exposition était de 8 mois (selon les logs nginx archivés).
Correction : Action immédiate (priorité 1) : désactiver /actuator/heapdump en production via management.endpoint.heapdump.enabled=false. Action complète : restreindre tous les endpoints Actuator via Spring Security avec authentification Basic ou OAuth2 ; limiter l'exposition à un port management séparé (management.server.port=8081) accessible uniquement depuis le réseau interne ; exposer uniquement les endpoints strictement nécessaires (typiquement /health avec management.endpoints.web.exposure.include=health) ; auditer tous les autres endpoints (/env, /configprops, /beans, /mappings, /metrics) qui peuvent leaker des informations sensibles. Rotation immédiate de tous les secrets / tokens qui pourraient avoir été compromis pendant la période d'exposition.
Référence : CVE-2023-20873 (Spring Boot Actuator) · CWE-200 (Exposure of Sensitive Information) · OWASP A05:2021 (Security Misconfiguration) · Spring Boot Security Guide 3.x · Veracode State of Software Security 2024
Pentest Spring Boot : options comparées
| — | Scan gratuit | Matproof Sentinel | Consultance classique |
|---|---|---|---|
| Moteur de scan automatisé | ✓ (aperçu 3 min) | ✓ Scan complet | ✗ Manuel uniquement |
| Couverture OWASP Top 10 | Partielle | ✓ Complète | ✓ Complète |
| Preuve d'exploitation | ✗ | ✓ Par finding | ✓ Par finding |
| Mapping réglementaire (DORA/NIS2/ISO 27001) | ✗ | ✓ Automatisé | ✓ Manuel |
| Rapport PDF prêt pour l'audit | ✗ | ✓ Instantané | ✓ Livraison 2–4 semaines |
| Scans continus / récurrents | ✗ | ✓ Par déploiement | ✗ Engagement annuel |
| Délai avant premier résultat | ~3 min | ~30 min scan complet | 2–4 semaines |
| Prix | €0 | À partir de €149 | €8 000–€25 000 |
| Revue de code source (SAST) | ✗ | ✓ Plan Growth | ✓ Périmètre défini |
| Tests API (REST/GraphQL) | ✗ | ✓ Automatisé | ✓ Manuel |
Forfaits pentest Spring Boot
- 1 scan pentest complet
- Résultats priorisés par IA avec CVSS 3.1
- Proof-of-exploit pour chaque finding
- Rapport PDF (prêt pour l'audit)
- Mapping réglementaire (DORA, NIS2, ISO 27001)
- Scans illimités (jusqu'à 3 domaines)
- Surveillance continue
- Intégration CI/CD (GitHub, GitLab)
- Tous les mappings réglementaires
- Support prioritaire
- Scans + domaines illimités
- Tests authentifiés / White-Box
- Tests d'API et d'infrastructure cloud
- Account manager sécurité dédié
- SLA réponse 24h
Questions fréquentes sur le pentest Spring Boot
Comment savez-vous si nous sommes encore vulnérables à Log4Shell trois ans après la divulgation ?
Nous testons activement avec des payloads JNDI dans tous les champs susceptibles d'être loggés (User-Agent, X-Forwarded-For, paramètres d'authentification, body JSON). Nous identifions aussi via JAR fingerprinting les versions Log4j présentes dans le classpath, y compris dans les dépendances transitives. Selon Cisco Talos, 31 % des serveurs Java en 2024 restent vulnérables — la longue traîne est due aux applications legacy avec des dépendances Java 8 figées, aux environnements air-gapped, et aux serveurs Tomcat / WebLogic embarqués avec Log4j 1.x EOL.
Quelle est la différence entre un scan automatisé Spring et un pentest manuel ?
Le scan automatisé (Matproof Sentinel Single Run, 149 €) détecte les CVEs connues (Log4Shell, Spring4Shell, CVE-2023-20861, etc.), les endpoints Actuator exposés, les misconfigurations Spring Security évidentes, et les vulnérabilités OWASP Top 10 standard. Le pentest manuel (plan Growth) ajoute la chasse aux gadgets de désérialisation custom, l'analyse approfondie des règles SecurityFilterChain complexes, le SpEL injection dans des contextes non triviaux, et l'analyse d'enchaînements multi-étapes spécifiques à votre logique métier. Pour des banques DORA Art. 24 ou systèmes BaFin BAIT, le pentest manuel reste recommandé.
Pouvez-vous tester nos endpoints Actuator avec authentification (basic auth, OAuth2) ?
Oui, dans les plans Starter et Growth nous testons les endpoints Actuator avec credentials de test fournis. Nous vérifions la rotation des credentials, la solidité des secrets utilisés, l'exposition des endpoints sensibles même derrière l'authentification (un attaquant authentifié pourrait toujours exfiltrer un heapdump), et les escalades de privilèges via /actuator/loggers (modification du niveau de log) ou /actuator/restart.
Notre application utilise WebFlux (Spring reactive) au lieu de Spring MVC. Les tests s'appliquent-ils ?
Oui. Spring WebFlux a son propre ensemble de vulnérabilités à tester : misconfigurations des WebFilter (équivalent reactive des Filters MVC), backpressure exploitation pour DoS, configurations CORS différentes entre WebFlux et MVC (source de bugs), et SecurityWebFilterChain (réactif) plutôt que SecurityFilterChain (servlet). Nous adaptons nos tests à votre stack reactive avec attention particulière aux opérateurs Reactor susceptibles de bloquer le scheduler.
Quels frameworks Java alternatifs à Spring Boot testez-vous ?
Notre couverture inclut tous les frameworks Java backend populaires : Spring Boot (3.x, 2.x), Quarkus, Micronaut, Jakarta EE (anciennement Java EE) sur Wildfly / Payara / OpenLiberty, Helidon, Vert.x, Play Framework, Dropwizard. Les classes de vulnérabilités sont largement communes (deserialization, configuration management endpoints, dépendances Log4j), avec des spécificités par framework adressées dans nos tests.
Comment intégrer Matproof Sentinel dans notre pipeline Maven / Gradle ?
Plan Starter ou Growth : nous fournissons un plugin Maven (matproof-sentinel-maven-plugin) et une task Gradle (matproof-sentinel-gradle-plugin) qui se branchent sur les phases verify ou check. À chaque build PR, un scan rapide (15 min) cible les changements ; un scan complet hebdomadaire sur le main / release branch. Les findings Critical/High peuvent bloquer le build via un seuil configurable. L'intégration GitHub Actions, GitLab CI, Jenkins, et CircleCI est documentée.
Le pentest Matproof Sentinel est-il accepté par les auditeurs DORA / BaFin BAIT pour la conformité Spring Boot ?
Oui. Notre rapport produit une cartographie explicite aux articles DORA Art. 24 (test d'intrusion régulier), DORA Art. 25 (vulnerability management), et BaFin BAIT §6.3 (tests applicatifs). Pour les banques BAIT, nous incluons les preuves d'audit Spring Boot spécifiques (versions, CVEs testées, endpoints Actuator audités). Pour DORA Art. 26 TLPT, Matproof Sentinel ne remplace pas un test red-team accrédité BCE mais peut le compléter pour la couverture continue entre tests TLPT triennaux.
Combien de temps prend un pentest Spring Boot complet ?
Le scan automatisé complet (couvrant Log4Shell, Spring4Shell, Actuator, SpEL injection, désérialisation, Spring Security misconfigurations, et OWASP Top 10) dure environ 90 minutes pour une application Spring Boot typique avec 50-100 endpoints. Pour des applications microservices (10+ services Spring), nous parallélisons les scans avec une durée totale de 3-4 heures. Le rapport audit-ready DORA / NIS2 / ISO 27001 est livré dans les 24 heures.
Approfondir — articles de blog associés
Sécurisez votre application Spring Boot maintenant
Premier scan en 3 minutes, pentest Spring Boot complet en 90 minutes incluant Log4Shell, Spring4Shell, et audit Actuator. Rapport audit-ready DORA / NIS2 / ISO 27001 dès 149 €.
Lancer le scan gratuit