JANUS: Synthesizing Cross-Layer Defenses Against Web Deserialization Attacks

What happened

Unsafe deserialization happens when an app rebuilds objects from untrusted bytes (Java serialization, PHP unserialize, and similar). Attacker-chosen types and fields can trigger a gadget chain: existing library methods that, called in sequence, end in remote code execution. Defenses usually sit at one layer and block one known exploit, and attackers switch chains or encodings to get around them. JANUS automates building layered defenses for a specific deployment.

1. Three layers, each with a blind spot.
   • Gateway (a WAF such as ModSecurity) sees request bytes, not rebuilt objects, so a different encoding slips by.
   • Application (type allowlists, deserialization filters) sees objects, but a different gadget chain from another dependency can pass.
   • System (syscall filters, container rules) sees the final action, but broad rules break legitimate features.
2. Red-blue loop. In an isolated offline copy of the deployment, a black-box attacker agent starts from a known exploit and tries variants: other gadget chains, other encodings, other entry points. It sees only what a real outside attacker would see.
3. Defender agent. For each verified variant, the defender summarizes its security-relevant effects. It uses counterfactual replay (re-running attacks with one control removed) to tell which controls add real coverage and which are redundant. It then picks and scopes controls across layers together.
4. Accept only safe policies. A candidate policy must block every exploit found so far and pass a regression suite of benign workflows within a latency budget.
5. Results on 16 vulnerable deployments across six Java and PHP apps (including a recent Jenkins RCE): held-out attack success fell to 6.2%, versus 18.8% to 55.0% for ModSecurity with the OWASP rules, Datadog RASP, OpenRASP, Kintsugi and Tetragon. JANUS fully mitigated 13 of 16 deployments, kept 98.4% of functionality tests passing, and added 6.9% to targeted p95 latency.

Why it works

One vulnerable entry point can admit many exploit paths, and which ones work depends on the libraries and runtime of that exact deployment. A generic rule set cannot know that. Testing against an adaptive attacker on a replica reveals the real set of viable paths.

Layering works because the blind spots differ. An encoding trick that fools the WAF still produces a forbidden type at the app layer; a new gadget chain that passes the type filter still makes a forbidden syscall. The hard part is coordination, and counterfactual replay gives the defender a way to measure what each control actually contributes.

The bigger pattern

This is defense in depth plus adversarial testing, automated: a fuzzing-style loop where each new bypass becomes a regression test for the next policy. It resembles how you would harden a system against chaos experiments, with functionality tests as the guard against overblocking.

What it means in practice

• Never deserialize untrusted input with native formats. Use JSON or Protobuf with explicit schemas. Check job queue payloads, caches and session stores, not only HTTP bodies.
• If you must, use an allowlist of types (Java ObjectInputFilter, PHP allowed_classes) and remove unused gadget-rich libraries.
• Do not count on a WAF alone; add container and syscall limits so a successful exploit cannot run a shell.
• Keep a benign-workflow test suite and a latency budget for every security rule change.
• Re-test after dependency upgrades, since new libraries bring new gadgets.