java-serialization-audit

Java serialization class vulnerability source code audit

This skill focuses on determining at the source code level whether "deserialization/XXE/SSTI holds true". The core work is: white-box confirmation of deserialization entry points, tracing data sources, evaluating available Gadget chains in the classpath, verifying XML parser security configurations, and checking template engine rendering contexts. Runtime black-box techniques such as constructing exploit payloads and sending remote exploit chains fall under the scope of the corresponding exploit skill.

In-depth reference

• Dangerous patterns / secure pattern code comparisons for 3 categories of vulnerabilities / Gadget dependency table / EVID evidence examples → references/serialization-patterns.md

---

Quick reference table for 3 categories of vulnerabilities

Type	Typical Sink	Exploitation conditions	Severity
Java deserialization	ObjectInputStream.readObject(), XMLDecoder.readObject()	User-controllable serialized stream + available Gadget Chain in the classpath	Critical
XXE	DocumentBuilderFactory, SAXParser, XMLInputFactory, TransformerFactory, SchemaFactory	External entities/DTD not disabled + user-controllable XML input	High-Critical
SSTI	Velocity.evaluate, FreeMarker Template, Thymeleaf preprocessing expression	User input directly enters the template compilation/rendering context	Critical

Java deserialization audit key points

• Entry point identification: ObjectInputStream.readObject()、ObjectInputStream.readUnshared()、XMLDecoder.readObject(), custom readObject/readResolve/readExternal additional attack surface in implementations
• Data source tracing: HTTP request body (magic bytes AC ED 00 05 or Base64-encoded rO0AB), RMI/JMX remote invocation, JMS message queues, Redis/Memcached cache deserialization, file reads, ViewState, Cookie/Session serialized storage
• Gadget availability assessment: Check pom.xml/build.gradle and whether dependencies of known Gadget chains exist in the classpath (commons-collections 3.x/4.x, commons-beanutils, spring-core, Groovy, hibernate-core, etc.), and whether the versions are within the affected range
• Defense mechanism verification: JEP 290 ObjectInputFilter whether configured, whitelist vs blacklist strategy,SerialKiller/NotSoSerial whether third-party protection libraries such as these are enabled,resolveClass whether rewritten as whitelist validation
• readResolve/readObject custom logic: Even if no general-purpose Gadget exists, behaviors such as file operations, network requests, and dynamic class loading in custom deserialization methods also constitute attack surface

XXE audit key points

• Secure configuration of 5 XML parsers:
  • DocumentBuilderFactory: setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)
  • SAXParserFactory: Same as above + setFeature("http://xml.org/sax/features/external-general-entities", false) + setFeature("http://xml.org/sax/features/external-parameter-entities", false)
  • XMLInputFactory (StAX): setProperty(XMLInputFactory.SUPPORT_DTD, false) + setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false)
  • TransformerFactory: setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "") + setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, "")
  • SchemaFactory: setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "") + setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "")
• Data flow analysis: XML input sources (HTTP request body, file upload, SOAP message, SVG/Office file) → enter parser → parsing result echoed back (direct XXE) or not echoed back (blind injection/out-of-band OOB)
• Java-specific protocols: jar: protocol can trigger remote file download and decompression,netdoc: protocol (older JDK) is equivalent to file://

Template injection SSTI audit key points

• Velocity: Velocity.evaluate(context, writer, tag, userTemplate) — if userTemplate parameter is user-controllable then direct RCE
• FreeMarker: new Template("t", new StringReader(userInput), cfg).process(dataModel, writer) — user input compiled as template source is dangerous
• Thymeleaf: controller return value concatenation leads to SSTI,return "user/" + input when input can inject __${expr}__ preprocessing expression triggers SpEL → RCE
• Secure pattern: template name/path whitelist, FreeMarker setting TemplateClassResolver.ALLOWS_NOTHING_RESOLVER Disabled ?new() Built-in functions, Velocity usage SecureUberspector, Thymeleaf restricts view names from concatenating user input

Detection Checklist

• All ObjectInputStream.readObject()/XMLDecoder.readObject() call sites have been reviewed one by one
• Data sources of deserialization entry points (HTTP/RMI/JMS/cache/file) have been traced and confirmed
• Classpath dependencies have been checked for known Gadget Chain libraries and their affected versions
• Defense mechanisms such as JEP 290 ObjectInputFilter / SerialKiller / whitelist resolveClass have been verified
• Additional attack surface in custom readObject/readResolve methods has been investigated
• Secure Feature configurations for the 5 XML parsers have been confirmed one by one
• XML input sources (request body/upload/SOAP/SVG) and echo methods have been analyzed
• User input controllability at Velocity/FreeMarker/Thymeleaf template rendering entry points has been checked
• Template engine security modes (sandbox/whitelist/disabling dangerous functions) have been verified
• Severity scoring uses a unified formula, consistent with the pipeline