Protection de l’application Web Tomcat

tomcat : Convertir un WAR en une base Tomcat autonome. Lors de l’exécution, les composants Tomcat intégrés à l’encodeur sont utilisés, sans nécessiter de lire l’installation Tomcat locale de l’utilisateur.

1. Opérations via l’interface graphique

1. Sélectionner Tomcat WAR sur la page du type d’application.

   

2. Sélectionner l’entrée WAR, Version Java incluse et la plateforme cible, puis choisir entre le mode simple et le mode avancé.

   

3. Avec le mode avancé, choisir Tomcat 9/10.1 ou conserver la détection automatique, et configurer le Context Path, les paramètres JVM et les règles d’exclusion selon les besoins; le mode simple propose des versions de Tomcat via un scan de compatibilité. La signification de chaque option est expliquée dans Paramètres du mode avancé de Protector4J.

   

4. Sélectionner le répertoire de sortie, vérifier le résumé des paramètres, puis cliquer sur Run protection.

   

2. Exemples CLI

Chemin Context spécifié:

p4j tomcat app.war dist --context /app

Analyse de compatibilité et recommandations d’application automatique:

p4j tomcat app.war --compat-scan
p4j tomcat app.war dist --compat-apply --context /app

Ces deux options ne peuvent pas être utilisées en même temps. Leurs différences sont les suivantes:

Pour tomcat et --compat-apply, il est possible d’ajouter des classes d’exclusion en fonction des résultats du scan, ainsi que de modifier des options telles que la version de Tomcat, le ZIP overlay et le suffixe d’archive. Pour ces trois dernières options, les valeurs spécifiées explicitement dans la ligne de commande priment; les classes d’exclusion recommandées sont par défaut fusionnées avec celles spécifiées explicitement pour --exclude. Si vous ne souhaitez pas que des classes d’exclusion soient ajoutées automatiquement, vous pouvez également fournir --no-compat-excludes. Le scanneur ne réalise qu’une analyse heuristique statique; les problèmes nécessitant une modification du code ne seront pas automatiquement corrigés par --compat-apply, et des tests de régression sur la plateforme cible restent nécessaires après génération.

Pour connaître les autres commandes CLI, toutes les options, les variables d’environnement et les exemples d’automatisation, veuillez consulter Référence des paramètres CLI.

--tomcat-version est par défaut égal à auto. Si nécessaire, vous pouvez spécifier explicitement 9 ou 10.1 :

p4j tomcat app.war dist --context /app --tomcat-version 10.1

3. Structure de sortie

dist/
├── bin/
│   ├── catalina.sh
│   ├── startup.sh
│   ├── shutdown.sh
│   └── *.bat
├── conf/p4jx/
│   ├── contexts.list
│   ├── protected-classes.list
│   └── allowed-prefixes.list
├── protected/
│   └── app.p4jx
├── lib/
│   ├── p4jx-tomcat-runtime.jar
│   └── tomcat-runtime-deps.jar
├── vlxjre/
├── run.sh
└── run.bat

Un WAR physique n’est pas généré par défaut. web.xml, les ressources statiques, les classes publiques, les stubs de métadonnées ainsi que les implémentations de protection se trouvent dans protected/<context>.p4jx, et sont présentés à Tomcat par P4JX WebResourceSet.

4. Démarrage et arrêt

Exécution en mode frontend:

./run.sh

Démarrage en arrière-plan au style Tomcat:

./bin/startup.sh
./bin/shutdown.sh

Pour Windows, utilisez le fichier correspondant .bat. Les journaux sont écrits dans le répertoire de sortie logs/.

Lors du packaging pour Windows, il est également possible de générer un programme d’exécution natif supplémentaire afin de démarrer Tomcat intégré en mode frontend, voir Créer un lanceur EXE pour Windows.

Paramètres de démarrage de la JVM

Lors du packaging, vous pouvez saisir un paramètre par ligne dans l’interface GUI JVM startup options, ou utiliser la CLI:

p4j tomcat app.war dist \
  --context /app \
  --jvm-option -Xms1g \
  --jvm-option -Xmx2g

Modification directe après déploiement:

• macOS/Linux: modifiez bin/catalina.sh, ajoutez JVM_OPTS+=("-Xms1g" "-Xmx2g") après JVM_OPTS=(...) présent dans run_java() ; cela s’applique tant au démarrage en mode frontend que en arrière-plan via startup.sh.
• En arrière-plan sous Windows: modifiez bin\catalina.bat en ajoutant set "JVM_OPTS=%JVM_OPTS% -Xms1g -Xmx2g" après l’original set "JVM_OPTS=...".
• En arrière-plan sous Windows: ajoutez set "APP_JAVA_OPTS=-Xms1g -Xmx2g" avant l’appel de catalina.bat dans bin\startup.bat. Si vous souhaitez partager un même ensemble de paramètres persistants entre les modes arrière-plan et en premier plan, il est recommandé de les regénérer via la GUI/CLI.

Pour un démarrage temporaire, vous pouvez également définir APP_JAVA_OPTS avant la commande. Des exemples complets pour CMD, PowerShell et scripts se trouvent dans Configuration des paramètres de démarrage de la JVM.

5. Sélection de la version Tomcat

La détection automatique identifie en priorité les espaces de noms d’API à partir des classes d’application et des descriptions de déploiement; les noms des JAR pris en compte ne servent qu’à titre indicatif. Lorsque javax et jakarta sont utilisés ensemble, l’outil refuse de faire des suppositions automatiques.

6. JSP

Lorsqu’un WAR contient des JSP, ils sont automatiquement précompilés en classes servlet et en mappages URL au cours de l’étape de codage. Cela permet de respecter le périmètre de protection des définitions de classes en temps de exécution, car la compilation dynamique des JSP à ce moment-ci créerait de nouvelles classes depuis le répertoire de travail de Tomcat.

Contrôle explicite possible:

--precompile-jsp
--no-precompile-jsp

Il est recommandé de conserver la précompilation automatique par défaut dans un environnement de production. Lorsqu’elle est désactivée, les applications contenant JSP peuvent échouer lors de l’accès aux pages.

7. Champ de la protection et règles d’exclusion

Par défaut, les classes d’application de WEB-INF/classes sont protégées, tandis que WEB-INF/lib dépend de cette protection par défaut et n’est donc pas protégé. Il est possible d’exclure les classes destinées à être accessibles depuis le web:

p4j tomcat app.war dist \
  --context /app \
  --exclude 'com.example.web.**,com.example.dto.**'

Il est fortement recommandé d’exclure les servlets/filtres/listeners, les DTO, les fichiers de configuration, les entités, les classes de pontage JNI ainsi que les classes nécessitant une extension par le conteneur. Un scan de compatibilité fournira des recommandations prudentes.

8. Ajout d’une application dans le même paquet Tomcat

p4j tomcat second.war dist \
  --append-app \
  --context /second

Contraintes:

• Le chemin contextuel ne doit pas coïncider avec celui d’une application existante;
• Les applications anciennes et nouvelles doivent utiliser la même version majeure de Tomcat, la même version de Java ainsi que la même plateforme cible;
• Lorsque --append-app n’est pas fourni, l’outil refuse d’écrire dans un package Tomcat existant;
• Cochez “Append application to an existing Tomcat folder” dans l’interface graphique, puis sélectionnez directement un répertoire existant.

9. Précautions à prendre pour Java 8

La cible Java 8 active automatiquement le mécanisme ZIP overlay, permettant ainsi à Tomcat WebResourceSet d’ouvrir des archives protégées.