Защита веб-приложений Tomcat

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

1. Работа с интерфейсом GUI

  1. На странице типа приложения выберите Tomcat WAR.

    Выберите WAR-файл Tomcat

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

    Выберите способ ввода, версию Java, целевую платформу и режим работы

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

    Настройка версии Tomcat, Context Path и правил исключения

  4. Выберите каталог выходных файлов, проверьте краткое описание параметров, затем нажмите 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 APITomcatJava требует
javax.servlet.*Tomcat 9Java 8/11/17/21/25
jakarta.servlet.*Tomcat 10.1Java 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 открывать защищённые архивы.