Защита веб-приложений Tomcat
tomcat — преобразование WAR-файла в самодостаточную базу Tomcat. Во время работы используются встроенные в кодировщик компоненты Tomcat, без необходимости загружать установку Tomcat с пользовательского компьютера.
1. Работа с интерфейсом GUI
-
На странице типа приложения выберите Tomcat WAR.

-
Выберите исходный WAR-файл, Входящая версия Java и целевую платформу, а также определите режим работы — простой или продвинутый.

-
В режиме продвинутого использования выберите Tomcat 9/10.1 или оставьте опцию автоматического обнаружения, после чего настройте Context Path, параметры JVM и правила исключения по необходимости; в простом режиме версия Tomcat предлагается на основе сканирования на совместимость. Значение каждого параметра описано в Настройки режима «Продвинутый» для Protector4J.

-
Выберите каталог выходных файлов, проверьте краткое описание параметров, затем нажмите Run protection.

2. Примеры использования CLI
Указанный путь контекста:
p4j tomcat app.war dist --context /app
Сканирование совместимости и автоматические рекомендации по применению:
p4j tomcat app.war --compat-scan
p4j tomcat app.war dist --compat-apply --context /app
Эти два варианта нельзя использовать одновременно; их различия заключаются в следующем:
| Параметр | Поведение | Когда использовать |
|---|---|---|
--compat-scan | Производится только сканирование введённого WAR-файла, после чего выводятся информация о рисках и рекомендации по настройкам; кодирование не производится, файл dist не генерируется, поэтому выходной каталог не требуется. | Используется при первой защите приложения, обновлении зависимостей Tomcat, изменении области защиты или настройках JSP, а также при устранении проблем совместимости для просмотра отчёта. |
--compat-apply | После сканирования автоматически объединяются консервативные рекомендации, затем продолжается кодирование с формированием результата, поэтому необходимо указать каталог вывода. | После просмотра результатов сканирования и принятия автоматических рекомендаций они используются для завершения пакетирования; также могут применяться при повторной сборке с уже проверенными правилами или в процессах CI. |
Для tomcat и --compat-apply можно на основе результатов сканирования добавить классы исключения, а также настроить версию Tomcat, параметры ZIP overlay и суффиксы архивов. Для последних трех параметров приоритет имеют значения, явно указанные в командной строке; рекомендуемые классы исключения по умолчанию объединяются с явно указанными в --exclude. Если не хотите, чтобы классы исключения добавлялись автоматически, можно одновременно указать --no-compat-excludes. Сканер выполняет только статический гиперстимулированный анализ, проблемы, требующие изменения кода, не будут автоматически исправлены --compat-apply, поэтому после генерации необходимо провести тестирование на целевой платформе.
Для других команд CLI, всех параметров, переменных окружения и примеров автоматизации см. Справка по параметрам CLI.
По умолчанию --tomcat-version соответствует auto. При необходимости можно явно указать 9 или 10.1.
p4j tomcat app.war dist --context /app --tomcat-version 10.1
3. Структура вывода
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
По умолчанию физический WAR не генерируется. web.xml, статические ресурсы, публичные классы, метаданные-шаблоны и реализации защиты находятся в protected/<context>.p4jx, где они отображаются в Tomcat с помощью P4JX WebResourceSet.
4. Запуск и остановка
Работа в фоновом режиме:
./run.sh
Запуск в фоновом режиме в стиле Tomcat:
./bin/startup.sh
./bin/shutdown.sh
Для Windows используется соответствующий файл .bat. Логи записываются в каталог вывода logs/.
Параметры запуска JVM
Во время пакетирования можно вводить по одному параметру на строку в интерфейсе GUI JVM startup options или использовать CLI:
p4j tomcat app.war dist \
--context /app \
--jvm-option -Xms1g \
--jvm-option -Xmx2g
Прямая модификация после развертывания:
- macOS/Linux: отредактируйте
bin/catalina.sh, добавьтеJVM_OPTS+=("-Xms1g" "-Xmx2g")послеJVM_OPTS=(...)вrun_java()— это повлияет как на запуск в фоновом режимеstartup.sh, так и на работу в фоновом режиме. - Windows, режим в фоновом режиме: отредактируйте
bin\catalina.bat, добавьтеset "JVM_OPTS=%JVM_OPTS% -Xms1g -Xmx2g"после существующегоset "JVM_OPTS=...". - Фоновая работа в Windows: перед вызовом
catalina.batизbin\startup.batнеобходимо добавитьset "APP_JAVA_OPTS=-Xms1g -Xmx2g". Если требуется, чтобы один и тот же набор постоянных параметров использовался как в фоновом, так и в пользовательском режиме, рекомендуется их повторная генерация через GUI/CLI.
Для временного запуска также можно указать APP_JAVA_OPTS перед командой. Полные примеры для CMD, PowerShell и скриптов приведены в Настройка параметров запуска JVM.
5. Выбор версии Tomcat
| Пространство имен WAR API | Tomcat | Java требует |
|---|---|---|
javax.servlet.* | Tomcat 9 | Java 8/11/17/21/25 |
jakarta.servlet.* | Tomcat 10.1 | Java 11/17/21/25 |
Система автоматического обнаружения в первую очередь идентифицирует пространства имен API на основе классов приложений и описателей развертывания, причем названия зависимостей JAR используются лишь в качестве вспомогательных данных. При обнаружении смешивания javax и jakarta инструмент отклоняет любые автоматические предположения.
6. JSP
Когда в WAR-файле присутствуют JSP-файлы, они автоматически предкомпилируются на этапе кодирования в классы servlet и маппинги URL. Это делается для того, чтобы избежать динамической компиляции JSP во время выполнения, поскольку она приводит к созданию новых классов в рабочей директории Tomcat, что противоречит принципам «области защиты» и нарушает границы определения классов во время работы приложения. Таким образом обеспечивается «защита» «защищённого приложения» путём проведения «проверки совместимости» перед его запуском.
Возможен явный контроль:
--precompile-jsp
--no-precompile-jsp
В производственной среде рекомендуется сохранять стандартную настройку автоматической предкомпиляции. После её отключения приложения с JSP могут не работать при доступе к страницам.
7. Область защиты и правила исключения
По умолчанию защищаются классы приложения WEB-INF/classes, в то время как WEB-INF/lib по умолчанию остаётся незащищённым. Можно исключить классы, предназначенные для работы в веб-среде:
p4j tomcat app.war dist \
--context /app \
--exclude 'com.example.web.**,com.example.dto.**'
Особое внимание следует уделить исключению классов servlet/filter/listener, DTO, конфигурационных элементов, сущностей, классов JNI-мостов и классов, требующих усиления со стороны контейнера. Сканирование совместимости предоставит более осторожные рекомендации.
8. Добавление приложения в тот же пакет Tomcat
p4j tomcat second.war dist \
--append-app \
--context /second
Ограничения:
- Context path не должен совпадать с уже существующими приложениями;
- Как старые, так и новые приложения должны использовать одну и ту же основную версию Tomcat, версию Java и целевую платформу.
- При отсутствии передачи
--append-appинструмент отказывается записывать в существующий пакет Tomcat; - В интерфейсе GUI необходимо отметить опцию “Append application to an existing Tomcat folder” и напрямую выбрать существующую директорию.
9. Важные моменты при использовании Java 8
Для целей Java 8 автоматически включается функция ZIP overlay, что позволяет Tomcat WebResourceSet открывать защищённые архивы.