java-audit-pipeline

Java white-box audit overall methodology

White-box auditing discovers vulnerabilities at the source code level, focusing on "why the code is insecure." The actual exploitation techniques after discovering a vulnerability (constructing payloads, bypassing WAFs, weaponizing Gadget Chains) fall under the scope of black-box exploit skills. Java projects are often delivered as compiled .class / JAR / WAR files, so decompilation to restore the source code must be completed first (see decompile-strategy.md for details).

In-depth references

• Evidence contract system and scoring formula → references/evidence-contract.md
• Java dangerous function classification quick reference → references/sink-reference.md
• CFR decompilation strategy → references/decompile-strategy.md
• SAST toolchains such as Semgrep / SonarQube / CodeQL / Snyk → references/sast-toolchain.md

---

Audit 5-phase overview

Phase	Name	Core task	Deliverable
P1	Route mapping	Parse all entry points and their parameters	Route inventory
P2	Authorization modeling	Analyze authentication/authorization, flag exposed routes	Authorization matrix
P3	Data flow tracing	Full Source→Sink path tracing	EVID_* evidence set
P4	Categorized audit	In-depth inspection by Sink type	Vulnerability inventory
P5	Report assembly	Scoring + exploit chain orchestration	Audit report

Phase 1: Route mapping and entry point identification

Parse framework route configurations to build a complete attack surface inventory:

• Spring MVC: @RequestMapping, @GetMapping, @PostMapping and other composed annotations, scan all @Controller / @RestController classes
• Servlet: web.xml in the <servlet-mapping> as well as @WebServlet Servlets registered by annotation
• JAX-RS: @Path, @GET, @POST and other annotations, check Application resources registered by subclasses
• Struts2: struts.xml in the <action> mappings and ActionMapping wildcard rules
• WebService: CXF / Axis @WebService endpoints and WSDL publishing paths

Deliverable: route inventory, each record containing the URL path, Handler method signature, parameter binding method (@RequestParam / @PathVariable / @RequestBody), and whether authentication is required.

Phase 2: Authorization modeling and authentication review

Analyze the security framework's filter chain configuration to find routes lacking authentication protection:

• Spring Security: SecurityFilterChain / WebSecurityConfigurerAdapter in the antMatchers / requestMatchers rules
• Apache Shiro: shiroFilterChainDefinition URL-Filter mappings (anon / authc / perms)
• Custom interceptors: HandlerInterceptor.preHandle() registration scope and excluded paths
• Check the issuance and validation logic of JWT / Session / OAuth2 Token, and password storage methods (BCrypt / plaintext)

Phase 3: Data flow tracing (Source → Sink)

Every potential vulnerability path must produce EVID_* evidence points (see evidence-contract.md for details).

Three-layer analysis method:

1. — Global keyword scanning: search for Sink functions (refer to sink-reference.md) to quickly locate dangerous code areas Surface
2. Line — Trace variable flow line by line: trace back from Sink to Source, recording each step of variable propagation and filtering operations
3. Points — Verify exploitation conditions: confirm whether the filter can be bypassed, whether the parameters are controllable, and whether the execution path is reachable

Java-specific points of concern:

• Annotation-driven parameter binding (@RequestParam automatic trim,@RequestBody JSON deserialization) implicit conversion may swallow malicious input or introduce type confusion
• AOP aspects (@Around / @Before) may perform global filtering or logging at the aspect layer; it is necessary to confirm whether the aspect takes effect
• Reflective invocation (Method.invoke、Class.forName) interrupts static data flow tracking and requires manual follow-up
• Polymorphic dispatch — the actual implementation classes of interfaces/abstract classes must be investigated one by one; do not look only at the interface declaration

When a complete Source→Sink path cannot be traced, it can only be marked as "to be verified".

Phase 4: Categorized vulnerability audit

Dispatch by Sink type to the corresponding sub-skill for in-depth audit:

• Injection class (SQL / CMD / LDAP / SpEL / OGNL / EL)
• File class (read / upload / write / path traversal)
• Front-end class (XSS / CSRF / redirect)
• Serialization class (Java native deserialization / FastJSON / Jackson / XXE)
• Authentication and configuration class (privilege escalation / weak encryption / information leakage / Actuator exposure)
• Framework-specific vulnerabilities (known CVEs, Spring / Struts2 / Shiro configuration flaws)

Phase 5: Reporting and exploit chain assembly

Severity scoring: Score = R * 0.40 + I * 0.35 + C * 0.25(R=reachability, I=impact scope, C=exploitation complexity, each 0-3 points)

Combine multiple vulnerabilities on the same target into an exploit chain (e.g.: Actuator information leakage→Shiro authentication bypass→SpEL injection→RCE).

Audit quality checklist

• All public routes have been included in the route inventory (including implicit entry points registered by Servlet / Filter)
• All unauthenticated routes have been marked and prioritized for audit
• Every "confirmed" vulnerability has a complete EVID_* evidence chain
• The actual coverage of AOP aspects and global Filters has been verified
• The data flow of reflective invocations and dynamic proxies has been manually followed up
• Framework versions and dependency component versions have been confirmed, and known CVEs have been cross-checked
• Vulnerability scoring uses a unified formula, and severity classification is consistent
• The feasibility of the exploit chain has been verified at the source code level