Insecure Deserialization

Serialization turns an object into bytes to store or send; deserialization rebuilds it. Insecure deserialization is rebuilding an object from data the attacker controls and then trusting it — its fields, its signature, or even the class it names. At its worst, in languages with rich serialization, choosing the right type on the way back in leads straight to code execution.

These labs simulate serialization (base64 of JSON) and a gadget registry, so nothing real is executed and the lab engine is never touched. The behaviour — a reconstructed object trusted, a signature skipped, a gadget type triggering an action — mirrors the real bug.

What is the vulnerability?

• Trusting the rebuilt object. The session is a serialized {user, role}; the server deserializes it and trusts role. Flip it to admin.
• Unsigned-blob fallback. A signature is added, but verified only when present — strip it and the tampered object sails through.
• Gadget on deserialize. The deserializer builds the class named by a __type field and triggers its behaviour. A benign Report is fine; a Command gadget performs a server action and leaks data.

Why does it happen?

The format is treated as if it were trusted internal state, but it made a round trip through the client. Signatures help only if they are mandatory. And deserializers that instantiate arbitrary types hand the attacker a construction primitive — the famous “gadget chains”.

How do you stop it?

Keep sensitive state on the server with only a random id at the client, or sign it and require a valid signature every time. Never deserialize untrusted bytes into behavioural types — parse plain data against a schema and build your own objects from the validated fields.

The three labs below walk this: forge a session object, strip a signature, and fire a gadget.