| name | eresus-serialization-review |
| description | Serialization and deserialization security review skill for object mappers, parser pipelines, message formats, and state transfer mechanisms. Trigger when the user asks to: "review serialization security", "check deserialization", "audit Jackson/Fastjson/YAML/XML parsing", "look for gadget-chain risk", "review session or message deserialization", or wants a focused audit of parser-driven attack surface. Complements eresus-sast-scanner with a deep dive on serialization abuse paths.
|
| metadata | {"version":"1.0","domain":"application-security","mode":"targeted-review"} |
Serialization Security Review
Purpose
Find vulnerabilities caused by unsafe serialization, deserialization, object mapping, parser configuration,
and cross-boundary state transfer. Focus on cases where untrusted bytes, JSON, YAML, XML, cookies, view state,
cache blobs, or queue messages are turned into executable, privileged, or overly dynamic objects.
High-Risk Targets
Prioritize:
- Java native serialization and
ObjectInputStream
- Jackson polymorphic typing and unsafe default typing
- Fastjson auto-type behavior
- .NET
BinaryFormatter, LosFormatter, NetDataContractSerializer
- PHP
unserialize() and POP-chain entry points
- Python
pickle, marshal, and unsafe YAML loaders
- Node parsers that revive functions, prototypes, or constructors
- session cookies, view state, queue payloads, cache entries, and signed blobs crossing trust boundaries
Workflow
Step 1: Find Deserialization Boundaries
Locate where external or semi-trusted data is parsed, decoded, revived, or reconstructed:
- HTTP body parsers
- cookies and session stores
- file import handlers
- webhook processors
- message queue consumers
- cache/database blob readers
- mobile/app local state restores
Step 2: Classify the Input Trust Level
For each boundary, decide whether the input is:
- fully attacker-controlled
- user-controlled but signed/encrypted
- partner-controlled
- internal-only but reachable through weaker upstream systems
Do not assume "internal" means safe without an integrity guarantee.
Step 3: Identify Dangerous Parser Features
Look for:
- polymorphic type resolution
- class-name-based instantiation
- automatic object revival
- unsafe YAML/XML object construction
- magic methods, hooks, or callbacks triggered after deserialization
- prototype pollution or constructor abuse
- gadget-friendly libraries on the classpath or dependency tree
Step 4: Judge Exploitability
Confirm:
- the data crosses a trust boundary
- attacker influence reaches the parser
- type restrictions or integrity checks are absent, weak, or bypassable
- the resulting object graph has dangerous side effects or privileged behavior
Step 5: Recommend Safe Patterns
Prefer:
- explicit DTO binding
- strict schemas
- allowlisted concrete types
- data-only formats without executable behavior
- integrity validation before parsing
- safe parser defaults and feature disablement
Step 6: Report by Boundary
For each issue, state:
- boundary
- parser/serializer in use
- attacker control level
- impact
- exact hardening action
Guardrails
- Do not report plain serialization for output-only responses as a vulnerability by itself.
- Do not assume every JSON parser use is dangerous; focus on dynamic typing, unsafe features, and trust boundaries.
- Do not treat signed data as safe if the signing key is weak, leaked, or validation happens after parsing.
- Do not forget secondary entry points such as queues, caches, or admin import tools.
- Do not stop at
deserialize(); inspect post-deserialization hooks and object behavior.
Output Format
Use:
[SEVERITY] <serialization issue title>
Boundary: <entry point or state-transfer path>
File: <path>:<line>
Why it matters: <trust boundary + parser behavior + impact>
Fix: <concrete hardening action>
