This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Difference between revisions of "Deserialization Cheat Sheet"

Jump to: navigation, search
m (Point to the official site)
(51 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 [ GitHub]!
=What is Deserialization?=
Please visit [ 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.
Many programming languages offer a native capability for serializing their 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.
* Use the signing features of a language to assure that deserialized data has not been tainted.
Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
Implementation: Explicitly define final readObject() to prevent deserialization.
An example of this is:
private final void readObject(ObjectInputStream in)
throws {
    throw new"Cannot be deserialized");
Implementation: Make fields transient to protect them from deserialization.
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.
Implementation: Use a Java agent to override the internals of ObjectInputStream to prevent exploitation of known dangerous types as seen in rO0 and NotSoSerial
= References =
* [[Deserialization of untrusted data]]
= Authors and Primary Editors =
Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org<br/>
== Other Cheatsheets ==

Latest revision as of 14: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.