Most developers think of SQL injection, cross-site scripting, or authentication flaws when building secure Java applications. But lurking in the background is a critical, subtle and dangerous vulnerability: deserialization attacks.
In fact, this class of issues is recognised by OWASP as part of the Top 10:2021 security risks, specifically under #8: Software and Data Integrity Failures. And for good reason—Java deserialization vulnerabilities have led to some of the most high-profile exploits in the past decade, including remote code execution (RCE) vulnerabilities in widely used frameworks like Apache Commons Collections, WebLogic, and Jenkins.
What Are Deserialization Attacks?
Deserialization in Java is the process of reconstructing an object from its byte stream. It’s commonly used to exchange data between systems, persist objects, or transfer session state.
A deserialization attack happens when an application:
- Accepts untrusted serialized data, and
- Attempts to deserialize it without proper validation or restrictions.
This can lead to an attacker injecting crafted byte streams that instantiate arbitrary classes, often triggering dangerous behavior — such as arbitrary file writes, network calls, or even remote code execution.
Example Attack Flow
- Vulnerable code accepts serialized Java objects over a network or from client input.
- Attacker crafts a malicious payload using a known gadget chain (e.g., via Apache Commons Collections).
- Upon deserialization, the payload is executed, leading to arbitrary code execution on the server.
It’s stealthy, often difficult to detect, and devastating when successfully executed.
Why It’s Dangerous
- No user interaction required – Deserialization often happens behind the scenes.
- Trusted libraries become weapons – Known classes can be chained (aka “gadget chains”) to produce malicious effects.
- Difficult to patch retroactively – Fixing such vulnerabilities requires a deep dive into how objects are constructed and handled.
Common Sources of Risk in Java
ObjectInputStreamusage with untrusted data.- Frameworks and libraries that allow object binding (e.g., Spring, Jackson) without secure configuration.
- RMI, JMS, or HTTP-based services that accept serialized objects from external sources.
How to Protect Your Java Applications
Here are several best practices for defending against deserialization vulnerabilities:
1. Never deserialize untrusted input
Avoid deserializing data from users or external systems unless absolutely necessary. If you must, ensure it’s from a trusted, authenticated source.
2. Use safe serialization alternatives
Consider safer formats like JSON or XML, and libraries like Jackson or Gson. But beware: even these can have risks if misconfigured (e.g., polymorphic type handling).
3. Implement object whitelisting
When using Java’s native deserialization (ObjectInputStream), override resolveClass() to allow only specific, known classes.
@Override
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException {
if (!allowedClasses.contains(desc.getName())) {
throw new InvalidClassException("Unauthorized deserialization attempt", desc.getName());
}
return super.resolveClass(desc);
}Caution: Don’t do it the other way around and implement a blacklist.
4. Isolate deserialization code
Run deserialization in a restricted sandbox or low-privilege environment where any unexpected behavior is contained.
5. Keep libraries up to date
Stay current with patches and security updates—many deserialization vulnerabilities are due to outdated dependencies.
6. Use security tools
Static analysis (SAST) and dynamic scanning (DAST) tools can help catch insecure deserialization patterns. Tools like ysoserial can simulate malicious payloads for testing.
Final Thoughts
Deserialization attacks in Java are subtle but potent. They exploit the very convenience features we rely on to make software modular and flexible. As developers and architects, it’s our job to ensure that flexibility doesn’t come at the cost of security.
👨💻 If you’re developing Java applications and want to safeguard them against deserialization, XXE, and similar security flaws, I’m here to help. I offer consulting, code reviews, and secure development guidance tailored to your needs.
👉 Feel free to get in touch with me for a personal consultation or hands-on support. Let’s make your application bulletproof together!
Stay safe, code smart! 😎
📚 Check out also my other posts, e.g. Understanding XXE Attacks in Java.