Protección de aplicaciones web de Tomcat

tomcat: Convierte un WAR en una base de Tomcat autocontenida. Utiliza los componentes de Tomcat integrados en el codificador en tiempo de ejecución, sin necesidad de leer la instalación de Tomcat del equipo del usuario.

1. Operaciones mediante GUI

  1. En la página de tipo de aplicación, seleccione Tomcat WAR.

    Elegir WAR de Tomcat

  2. Elija “Ingresar WAR”, Versión de Java incluida en el paquete y la plataforma de destino, y seleccione el modo simple o el modo avanzado.

    Seleccione la entrada, la versión de Java, la plataforma de destino y el modo.

  3. Al usar el modo avanzado, elija Tomcat 9/10.1 o mantenga la detección automática, y configure según sea necesario la ruta de contexto, los parámetros de JVM y las reglas de exclusión; el modo simple sugiere una versión de Tomcat a través de un análisis de compatibilidad. Para conocer el significado de cada opción, consulte Configuración del modo avanzado de Protector4J.

    Configurar la versión de Tomcat, el Context Path y las reglas de exclusión

  4. Elija la carpeta de salida, revise el resumen de parámetros y luego haga clic en Run protection.

    Elige la carpeta de salida y ejecuta la protección

2. Ejemplos de CLI

Ruta de contexto especificada:

p4j tomcat app.war dist --context /app

Análisis de compatibilidad y sugerencias automáticas de aplicación:

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

Estas dos opciones no se pueden utilizar al mismo tiempo; su diferencia es la siguiente:

OpciónComportamientoCuándo usarla
--compat-scanSolo escanea el WAR de entrada, imprime los riesgos y las sugerencias de configuración y luego se cierra; no realiza codificación ni genera dist, por lo que no se necesita un directorio de salida.Úsala primero para ver los informes al proteger una aplicación por primera vez, al actualizar las dependencias relacionadas con Tomcat, al ajustar el alcance de protección o la configuración de JSP, así como al resolver problemas de compatibilidad.
--compat-applyDespués del escaneo, se combinan automáticamente las recomendaciones conservadoras y luego se continúa con la codificación para generar la salida; por lo tanto, es necesario especificar la carpeta de salida.Cuando se han leído los resultados del escaneo y se han aceptado las recomendaciones automáticas, se utiliza esto para completar el empaquetado; también puede emplearse en construcciones repetidas con reglas verificadas o en flujos CI.

Para tomcat y --compat-apply, se pueden añadir clases de exclusión según los resultados del escaneo, y ajustar opciones como la versión de Tomcat, el ZIP overlay y el sufijo del archivo archivado. Para estas tres últimas opciones, prevalecen los valores especificados explícitamente en la línea de comandos; las clases de exclusión recomendadas se combinan por defecto con las especificadas explícitamente en --exclude. Si no se desea añadir clases de exclusión automáticamente, se puede pasar también --no-compat-excludes. El escáner solo realiza un análisis heurístico estático; los problemas que requieren modificar el código no se repararán automáticamente con --compat-apply, y aún será necesario realizar pruebas de regresión en la plataforma de destino después de la generación.

Para otras órdenes CLI, todas las opciones, variables de entorno y ejemplos de automatización, consulte Referencia de parámetros de la CLI.

--tomcat-version tiene como valor por defecto auto. Si es necesario, se puede especificar explícitamente 9 o 10.1.

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

3. Estructura de salida

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

Por defecto, no se genera un WAR físico. web.xml, los recursos estáticos, las clases públicas, los stubs de metadatos y las implementaciones de protección se encuentran en protected/<context>.p4jx, y son presentados a Tomcat por P4JX WebResourceSet.

4. Inicio y detención

Ejecución en la interfaz frontal:

./run.sh

Inicio en segundo plano al estilo Tomcat:

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

En Windows se utiliza el archivo correspondiente .bat. Los registros se escriben en logs/, que se encuentra en el directorio de salida.

Al empacar para Windows también se puede generar un programa de inicio nativo adicional, que inicia Tomcat de forma integrada en la interfaz frontal; consulte Generar un iniciador EXE para Windows.

Parámetros de inicio de la JVM

Durante el empaquetado, se puede ingresar un parámetro por línea en JVM startup options de la GUI, o bien utilizar la CLI:

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

Modificación directa después del despliegue:

  • macOS/Linux: edite bin/catalina.sh; añada JVM_OPTS+=("-Xms1g" "-Xmx2g") después de JVM_OPTS=(...) en run_java(), lo cual surtirá efecto tanto para el inicio en la interfaz frontal como en segundo plano en startup.sh.
  • En primer plano de Windows: edite bin\catalina.bat e inserte set "JVM_OPTS=%JVM_OPTS% -Xms1g -Xmx2g" después del original set "JVM_OPTS=...".
  • En segundo plano de Windows: agregue set "APP_JAVA_OPTS=-Xms1g -Xmx2g" antes de llamar a catalina.bat en bin\startup.bat. Si se desea compartir un mismo conjunto de parámetros persistentes entre los modos de primer y segundo plano, se recomienda generarlos nuevamente a través de GUI/CLI.

También es posible establecer APP_JAVA_OPTS antes de la orden de inicio temporal. Ejemplos completos para CMD, PowerShell y scripts se encuentran en Configuración de parámetros de inicio de la JVM.

5. Selección de versión de Tomcat

Espacio de nombres de la API WARTomcatRequisitos de Java
javax.servlet.*Tomcat 9Java 8/11/17/21/25
jakarta.servlet.*Tomcat 10.1Java 11/17/21/25

La detección automática prioriza identificar los espacios de nombres de la API a partir de las clases de la aplicación y los descriptores de despliegue; los nombres de los archivos JAR se utilizan únicamente como evidencia adicional. Cuando se detecta el uso mixto de javax y jakarta, la herramienta rechaza hacer conjeturas automáticas.

6. JSP

Cuando un WAR contiene JSP, por defecto se precompilan automáticamente en clases servlet y mapeos de URL durante la fase de codificación. Esto se debe a que la compilación dinámica de JSP en tiempo de ejecución define nuevas clases desde el directorio de trabajo de Tomcat, lo cual no cumple con los límites de protección de las definiciones de clases en tiempo de ejecución.

Se puede controlar de forma explícita:

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

Se recomienda mantener la compilación previa automática por defecto en entornos de producción. Al desactivarla, las aplicaciones que contienen JSP podrían fallar al acceder a las páginas.

7. Ámbito de la protección y reglas de exclusión

De forma predeterminada, se protegen las clases de aplicación de WEB-INF/classes, mientras que WEB-INF/lib depende de la configuración por defecto de no protección. Se pueden excluir clases orientadas a la web:

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

Es importante excluir servlets, filtros, listeners, DTOs, configuraciones, entidades, clases de enlace JNI y aquellas que requieren mejoras por parte del contenedor. El análisis de compatibilidad ofrecerá recomendaciones conservadoras.

8. Añadir aplicaciones al mismo paquete de Tomcat

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

Restricciones:

  • La ruta de contexto no puede repetirse con ninguna aplicación existente;
  • Las aplicaciones nuevas y existentes deben utilizar la misma versión principal de Tomcat, la misma versión de Java y la misma plataforma de destino;
  • Cuando no se proporciona --append-app, la herramienta rechaza escribir en los paquetes de Tomcat existentes;
  • En la interfaz gráfica, se debe marcar “Append application to an existing Tomcat folder” y seleccionar directamente un directorio existente.

9. Consideraciones importantes para Java 8

El destino Java 8 activará automáticamente ZIP overlay, lo que permite que Tomcat WebResourceSet abra archivos archivados protegidos.