Difference between revisions of "Deserialization Cheat Sheet"

Jump to: navigation, search
(Using Alternative Data Formats)
m (Point to the official site)
(40 intermediate revisions by 11 users not shown)
Line 1: Line 1:
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>
This article is focused on providing clear, simple, actionable guidance for safely deserializing untrusted data in your applications.
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!
=What is Deserialization?=
Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html Deserialization Cheat Sheet] to see the latest version of the cheat sheet.
Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications. Deserialization is the reverse of that process -- taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.
However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.
=Guidance on Deserializing Objects Safely=
The following language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.
The following techniques are all good for preventing attacks against deserialization against [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html Java's Serializable format].
Implementation: In your code, override the ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like SerialKiller.
Implementation: Use a safe replacement for the generic readObject() method as seen here. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.
===Prevent Data Leakage and Trusted Field Clobbering===
If there are members of the object graph that should never be controlled by end users during deserialization or exposed to users during serialization, they should be marked with [https://docs.oracle.com/javase/7/docs/platform/serialization/spec/serial-arch.html#6250 the <code>transient</code> field].
===Prevent Deserialization of Domain Objects===
Some of your application objects may be forced to implement Serializable due to their hierarchy. To guarantee that your application objects can't be deserialized, a <code>readObject()</code> should be declared (with a <code>final</code> modifier) which always throws an exception.
<pre>private final void readObject(ObjectInputStream in) throws java.io.IOException {
  throw new java.io.IOException("Cannot be deserialized");
===Harden Your Own java.io.ObjectInputStream===
The <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. This is the best solution if:
* You can change the code that does the deserialization
* You know what classes you expect to deserialize
The general idea is to override [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass(java.io.ObjectStreamClass) <code>ObjectInputStream.html#resolveClass()</code>] in order to restrict which classes are allowed to be deserialized. Because this call happens before a <code>readObject()</code> is called, you can be sure that no deserialization activity will occur unless the type is one that you wish to allow.  A simple example of this shown here, where the the LookAheadObjectInputStream class is guaranteed not to deserialize any other type besides the Bicycle class:
<pre>public class LookAheadObjectInputStream extends ObjectInputStream {
    public LookAheadObjectInputStream(InputStream inputStream) throws IOException {
    * Only deserialize instances of our expected Bicycle class
    protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
            ClassNotFoundException {
        if (!desc.getName().equals(Bicycle.class.getName())) {
            throw new InvalidClassException(
                    "Unauthorized deserialization attempt",
        return super.resolveClass(desc);
More complete implementations of this approach have been proposed by various community members:
* [https://github.com/ikkisoft/SerialKiller NibbleSec] - a library that allows whitelisting and blacklisting of classes that are allowed to be deserialized
* [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications Contrast Security] - a utility method that allows whitelisting of classes to deserialize, as well as other thresholds.
* [https://www.ibm.com/developerworks/library/se-lookahead/ IBM] - the seminal protection, written years before the most devastating exploitation scenarios were envisioned.
===Harden All java.io.ObjectInputStream Usage with an Agent===
As mentioned above, the <code>java.io.ObjectInputStream</code> class is used to deserialize objects. It's possible to harden its behavior by subclassing it. However, if you don't own the code or can't wait for a patch, using an agent to weave in hardening to <code>java.io.ObjectInputStream</code> is the best solution. ct)]
Globally changing ObjectInputStream is only safe for blacklisting known malicious types, because it's not possible to know for all applications what the expected classes to be deserialized are. Fortunately, there are very few classes needed in the blacklist to be safe from all the known attack vectors, today. It's inevitable that more "gadget" classes will be discovered that can be abused. However, there is an incredible amount of vulnerable software
exposed today, in need of a fix. In some cases, "fixing" the vulnerability may involve re-architecting messaging systems and breaking backwards compatibility as developers move towards not accepting serialized objects.
To enable these agents, simply add a new JVM parameter:
Agents taking this approach have been released by various community members:
* [https://github.com/gocd/invoker-defender Invoker Defender by Go-CD]
* [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0 by Contrast Security]
* [https://www.contrastsecurity.com Contrast Enterprise by Contrast Security (commercial product)]
A similar, but less scalable approach would be to manually patch and boostrap your JVM's ObjectInputStream. Guidance on this approach is available [https://github.com/wsargent/paranoid-java-serialization here].
= Language-Agnostic Methods for Deserializing Safely =
==Using Alternative Data Formats==
A great reduction of risk is achieved by avoiding native deserialization formats. By switching to a pure data format like JSON or XML, you lessen the chance of custom deserialization logic being repurposed towards malicious ends.
Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating a separate domain of objects for the explicit purpose data transfer. Of course, it's still possible that the application will make security mistakes after a pure data object is parsed.
==Only Deserialize Signed Data==
If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then to choose not to deserialize any message which didn't have an authenticated signature.
= References =
* [[Deserialization of untrusted data]]
= Authors and Primary Editors =
Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br/>
== Other Cheatsheets ==

Latest revision as of 08:06, 15 July 2019


The Cheat Sheet Series project has been moved to GitHub!

Please visit Deserialization Cheat Sheet to see the latest version of the cheat sheet.