The deserialization security issue is commonly seen in Java, and is a Remote Code Execution (RCE) attack. Serialization is the process in Java of converting the state of an object into a byte stream (serialized object), which can be stored in files, memory, or a database. Deserialization is the reverse process, creating an object based on the byte stream.
For the deserialization attack, the serialized object becomes one of untrusted data input for the receiver to do the deserialization. The attack may tamper with or replace the serialized object with malicious code. This can be referred to in CWE-502: Deserialization of untrusted data http://cwe.mitre.org/data/definitions/502.html
The serialized object can be stored or transmitted by memory, files, and networks. The hacker may tamper with the serialized object or inject malicious code so that the reader/receiver of the serialized object will be vulnerable to injection attacks:
To discern whether our Java project is vulnerable to the deserialization security issue, we can look for specific deserialization behaviors with API keywords. Although we can't completely automate code scanning here, we can at least narrow the scope of the review area:
|
Programming language |
Source code patterns for potential deserialization security issues |
|
Java |
XMLDecoder | XStream | readResolve | readExternal | ObjectInputSteam | readObject | readObjectNoData | java.lang.reflect.InvocationHandler | MethodHandler.invoke | Object.finalize | |
If none of the APIs listed here have been used, we don't need to worry much about the deserialization security issue. However, if one of APIs has been used in the source code, then it warrants further investigation; one of the following mitigations can be implemented:
- Whitelisting or blacklisting the deserialized class
- Adoption of any look-ahead Java deserialization library, such as SerialKiller