eresus-serialization-review

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>