Add AppSec multipart filenames and file content detection for GlassFish/Payara

[jandro996]

What Does This Do

Instruments org.apache.catalina.fileupload.Multipart.getParts() — a GlassFish/Payara-specific class that does not exist in standard Tomcat — to report uploaded file names and file contents to the AppSec WAF via the server.request.body.filenames and server.request.body.files_content IG events.

Key design choice — direct javax.servlet.http.Part cast instead of reflection:

On Java 11+ with GlassFish/Payara, reflective Method.invoke() from an injected ByteBuddy helper (unnamed module) to PartItem (GlassFish named module) fails with IllegalAccessException — and setAccessible(true) is also blocked by the module system. The fix is to cast each part object directly to javax.servlet.http.Part inside the @Advice.OnMethodExit body. Because ByteBuddy inlines the advice into the target class (org.apache.catalina.fileupload.Multipart), the advice body runs in the same classloader/module context as PartItem, so virtual dispatch through the Part interface works without any reflective access. No helperClassNames() override is needed.

Changes:

• GlassFishMultipartInstrumentation: new InstrumenterModule.AppSec for org.apache.catalina.fileupload.Multipart
  • Hooks getParts() on exit; casts each element to javax.servlet.http.Part
  • Calls getSubmittedFileName() to distinguish file uploads from form fields (null → skip, empty string → file without name)
  • Fires requestFilesFilenames callback if any filenames are found
  • Fires requestFilesContent callback (guarded by contents.size() < maxFiles) using MultipartContentDecoder.readInputStream
  • Blocking action handling for both callbacks with effectivelyBlocked()
  • muzzleDirective() returns "glassfish" to exclude from the from703 assertInverse=true Tomcat muzzle check
• build.gradle (tomcat-appsec-7.0):
  • Added glassfish muzzle pass block (org.glassfish.main.extras:glassfish-embedded-all:[4.0,])
  • Added compileOnly javax.servlet:javax.servlet-api:3.1.0 — Part.getSubmittedFileName() was introduced in Servlet 3.1 (GlassFish 4+ = Java EE 7); tomcat-catalina:7.0.4 ships only Servlet 3.0
• ParameterCollector: added setAccessible(true) after each getMethod() call in resolveAndCache() (defensive; used by ParsePartsInstrumentation on Tomcat where reflection is still the correct approach)

Motivation

GlassFish and Payara (GlassFish-based) use a different multipart parsing path than standard Tomcat: Request.getParts() delegates to org.apache.catalina.fileupload.Multipart.getParts() instead of Request.parseParts(). The existing Tomcat instrumentation (ParsePartsInstrumentation) hooks parseParts() and is therefore never triggered on GlassFish/Payara, leaving file upload events unreported to the WAF.

Jira ticket: APPSEC-61873

Additional Notes

Why inlining beats helper injection for GlassFish:

The Java Platform Module System (JPMS) on Java 11+ enforces strong encapsulation for named modules. GlassFish packages org.apache.catalina.fileupload.PartItem in a named module; ByteBuddy-injected helpers run in the unnamed module. Method.setAccessible(true) does not cross this boundary, so reflective invocation silently fails (caught by catch (Exception ignored) in the helper) and no data reaches the WAF. The advice inlining mechanism sidesteps this entirely — the inlined bytecode is part of the Multipart class itself, in the same module as PartItem, so all method calls through the javax.servlet.http.Part interface resolve normally via virtual dispatch.

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors

Jira ticket: APPSEC-61873

Note: Once your PR is ready to merge, add it to the merge queue by commenting /merge. /merge -c cancels the queue request. /merge -f --reason "reason" skips all merge queue checks; please use this judiciously, as some checks do not run at the PR-level. For more information, see this doc.