Schutz für Tomcat-Web-Anwendungen

tomcat: Konvertiert eine WAR-Datei in eine selbstständige Tomcat-Basis. Während der Ausführung werden die im Encoder enthaltenen Tomcat-Komponenten verwendet, ohne dass die lokale Tomcat-Installation des Benutzers gelesen wird.

1. GUI-Bedienung

1. Wählen Sie auf der Anwendungsart-Seite Tomcat WAR aus.

   

2. Wählen Sie die Eingabedatei WAR, Die mitgelieferte Java-Version sowie die Zielplattform aus und entscheiden Sie sich zwischen Einfachmodus oder Fortgeschrittenem Modus.

   

3. Im Fortgeschrittenen Modus wählen Sie Tomcat 9/10.1 aus oder lassen Sie die automatische Erkennung zu, und legen Sie gegebenenfalls Context Path, JVM-Parameter sowie Ausschlussregeln fest; im Einfachmodus wird auf der Grundlage einer Kompatibilitätsprüfung eine Tomcat-Version vorgeschlagen. Die Bedeutung der einzelnen Optionen finden Sie bei Einstellungen für den Fortgeschrittenen-Modus von Protector4J.

   

4. Wählen Sie den Ausgabekatalog aus, überprüfen Sie den Parameterzusammenfassung und klicken Sie anschließend auf Run protection.

   

2. CLI-Beispiele

Specifizierter Context Path:

p4j tomcat app.war dist --context /app

Kompatibilitätsprüfung sowie automatische Anwendungsempfehlungen:

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

Diese beiden Optionen können nicht gleichzeitig verwendet werden; der Unterschied zwischen ihnen ist:

Für tomcat und --compat-apply können auf Basis der Scannergebnisse zusätzliche Ausnahmeklassen hinzugefügt werden, und Optionen wie die Tomcat-Version, das ZIP-overlay sowie die Archivendung können angepasst werden. Bei den letzten drei Optionen hat der aus der Kommandozeile ausdrücklich angegebene Wert Vorrang; die empfohlenen Ausnahmeklassen werden standardmäßig mit den ausdrücklich angegebenen für --exclude kombiniert. Falls keine automatische Hinzufügung von Ausnahmeklassen gewünscht ist, kann gleichzeitig --no-compat-excludes übergeben werden. Der Scanner führt lediglich eine statische heuristische Analyse durch – Probleme, die eine Codeanpassung erfordern, werden von --compat-apply nicht automatisch behoben; nach der Erstellung müssen sie weiterhin auf der Zielplattform durch Regressionstests überprüft werden.

Weitere CLI-Befehle, alle Optionen, Umgebungsvariablen und Automatisierungsbeispiele finden Sie unter Referenz für CLI-Parameter.

--tomcat-version ist standardmäßig gleich auto. Bei Bedarf kann explizit 9 oder 10.1 angegeben werden:

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

3. Schutzumfang: Der „Schutz“ umfasst den Schutz vor unbefugtem Zugriff sowie den Schutz der Daten innerhalb der geschützten Anwendung. Geschützte Anwendung: Eine geschützte Anwendung ist eine Anwendung, die durch spezielle Sicherheitsmaßnahmen vor externen Angriffen abgeschirmt wird. Kompatibilitätsprüfung: Vor der Verwendung ist eine Kompatibilitätsprüfung unerlässlich, um sicherzustellen, dass alle Komponenten zusammen funktionieren. Schutz: Zentraler Bestandteil des Schutzes ist die Erkennung und Abschirmung potenzieller Bedrohungen.

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

Standardmäßig wird kein physischer WAR erzeugt. web.xml, statische Ressourcen, öffentliche Klassen, Metadaten-Stubs sowie die Schutzimplementierungen befinden sich in protected/<context>.p4jx und werden von P4JX WebResourceSet an Tomcat bereitgestellt.

4. Starten und Beenden

Vorgrundausführung:

./run.sh

Starten im Tomcat-Stil im Hintergrund:

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

Für Windows wird die entsprechende Datei .bat verwendet. Die Protokolle werden in den Ausgabekatalog geschrieben, in der Datei logs/.

JVM-Startparameter

Beim Paketieren kann man in der GUI in JVM startup options einen Parameter pro Zeile eingeben oder die CLI verwenden:

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

Direkte Anpassung nach der Bereitstellung:

• macOS/Linux: Bearbeiten Sie bin/catalina.sh und fügen Sie nach JVM_OPTS=(...) in run_java() JVM_OPTS+=("-Xms1g" "-Xmx2g") hinzu – dies wirkt sich sowohl bei Vorgrund- als auch bei Hintergrundstart unter startup.sh aus.
• Windows Vorgrund: Bearbeiten Sie bin\catalina.bat und fügen Sie nach dem ursprünglichen set "JVM_OPTS=..." set "JVM_OPTS=%JVM_OPTS% -Xms1g -Xmx2g" hinzu.
• Hintergrundbetrieb unter Windows: Fügen Sie vor dem Aufruf von catalina.bat von bin\startup.bat aus set "APP_JAVA_OPTS=-Xms1g -Xmx2g" hinzu. Wenn dieselben persistenten Parameter sowohl im Hintergrund- als auch im Vordergrundbetrieb verwendet werden sollen, wird empfohlen, diese über die GUI/CLI neu zu erzeugen.

Eine vorübergehende Aktivierung ist ebenfalls möglich, indem man APP_JAVA_OPTS vor dem Befehl festlegt. Vollständige Beispiele für CMD, PowerShell und Skripte finden Sie unter Konfiguration der JVM-Startparameter.

5. Auswahl der Tomcat-Version

Die automatische Erkennung versucht in erster Linie, API-Namenräume anhand von Anwendungsarten und Deployment-Deskriptoren zu identifizieren, wobei die Namen der abhängigen JAR-Dateien lediglich als unterstützende Hinweise dienen. Wenn eine Mischung aus javax und jakarta erkannt wird, weigert sich das Tool, automatisch Rückschlüsse zu ziehen.

6. JSP

Wenn WAR-Dateien JSP-Dateien enthalten, werden sie standardmäßig automatisch in der Kompilierungsphase zu Servlet-Klassen und URL-Abbildungen vorkompiliert. Der Grund dafür ist, dass eine dynamische JSP-Kompilierung zur Laufzeit neue Klassen aus dem Arbeitsverzeichnis von Tomcat erstellt, was nicht mit dem Schutz der Grenzen der laufzeitlichen Klassendefinitionen übereinstimmt.

Explizite Steuerung möglich:

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

In der Produktionsumgebung wird empfohlen, die Standard-Einstellung zur automatischen Vorkompilierung beizubehalten. Wenn diese deaktiviert wird, können Anwendungen mit JSP beim Aufrufen der Seiten fehlschlagen.

7. Schutzumfang und Ausschlussregeln

Standardmäßig werden die Anwendungsklassen unter WEB-INF/classes geschützt, während WEB-INF/lib standardmäßig ungeschützt bleibt. Web-zugängliche Klassen können ausgeschlossen werden:

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

Insbesondere sollten servlet/filter/listener, DTOs, Konfigurationen, Entitäten, JNI-Brückenklassen sowie Klassen, die durch den Container erweitert werden müssen, ausgeschlossen werden. Die Kompatibilitätsprüfung liefert vorsichtige Empfehlungen.

8. Hinzufügen einer Anwendung in derselben Tomcat-Paketstruktur

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

Einschränkungen:

• Der Context-Path darf nicht mit bereits vorhandenen Anwendungen übereinstimmen;
• Sowohl alte als auch neue Anwendungen müssen dieselbe Hauptversion von Tomcat, dieselbe Java-Version sowie dieselbe Zielplattform verwenden;
• Wenn --append-app nicht übergeben wird, weigert sich das Tool, in bereits vorhandene Tomcat-Pakete zu schreiben;
• Im GUI wird “Append application to an existing Tomcat folder” ausgewählt und direkt ein vorhandener Ordner ausgewählt.

9. Hinweise zu Java 8

Für das Java 8-Ziel wird automatisch ZIP overlay aktiviert, sodass Tomcat WebResourceSet geschützte Archivdateien öffnen kann.