deserialization

Insecure Deserialization Detection

Overview

Serialization flattens an in-memory object into bytes so it can be stored, cached, or sent; deserialization rebuilds an object from those bytes. Insecure deserialization is when an application rebuilds an object from data an attacker can influence — a cookie, a hidden field, an API body, a cache or queue entry, an uploaded file — and then trusts the result. It sits at the boundary where untrusted bytes are handed to a native object reader, and its defining property is that harm frequently occurs during the rebuild, before the application ever inspects what it got, because the format lets the input name which classes to construct and lifecycle hooks on those classes run automatically. The attacker is anyone who can supply or modify the blob; what they gain ranges from flipping a privilege field in reconstructed state, through steering the application's own file and path handling, to reaching code already present in the application or its dependencies that ends in command execution. This skill finds such flaws by locating every site where untrusted bytes reach an object reader, checking each site in parallel, and merging the results into <output_dir>/deserialization-results.md.

What it is NOT

• Ordinary data parsing (not a finding): reading JSON or XML into a fixed, declared structure — no type names taken from the input, no object graph rebuilt from input-specified classes, no lifecycle hooks on attacker data — is normal input handling. Test: can the input choose which class or type is instantiated? If not, it is parsing.
• XML external entities (/websec:xxe): entity and document-type resolution in an XML parser is a different mechanism with a different fix. A framework that maps XML onto objects can have both; separate them by asking whether the harm comes from entity resolution or from class instantiation.
• Prototype pollution (/websec:prototype-pollution): reshaping JavaScript objects through inherited properties is an inheritance quirk with no serialized graph and no lifecycle hooks on reconstructed classes. Test: is there a native object reader in the path at all?
• Token integrity (/websec:jwt): a signed token accepted without verification is a signature-validation flaw. It becomes this class only when the deserializer's own behaviour — type resolution or lifecycle hooks — is what is abused.
• Operating system command injection (/websec:os-command-injection): a shell or interpreter invoked on request data — a filename, an argument, a whole command string — is that class, even when the data arrived as a serialized blob and even when a gadget chain ends in Runtime.exec. Test: does the harm come from a process spawned on attacker input, or from the reconstruction itself — type resolution, a lifecycle hook, a setter running during readObject? Only the second is this class.
• Access control (/websec:access-control): if the reconstructed object carries a role or owner field that the application trusts, and the blob is not otherwise abusable, the missing control is server-side re-validation of identity. Report the deserialization here and note the authorization gap for that skill.
• File upload (/websec:file-upload): an uploaded file whose bytes reach an object reader is this skill's finding; the upload path is how it is delivered. Note the upload weakness separately.
• Not a finding: the presence of a library known to contain reachable code fragments, with no untrusted deserialization anywhere; a blob whose integrity is verified against a server-held key before the bytes reach the reader, with the key not otherwise exposed; a reader restricted by an allow-list of permitted types that excludes everything outside a small declared set; internal-only deserialization of data no external party can influence, where that isolation is demonstrated rather than assumed.