Difference between revisions of "Deserialization Cheat Sheet"

From OWASP
Jump to: navigation, search
m
m
Line 8: Line 8:
 
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.
 
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.
+
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=
 
=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 language-specific guidance attempts to enumerate safe methodologies for deserializing data that can't be trusted.  
  
 
==Java==
 
==Java==
The following techniques are all good for preventing attacks against deserialization.
+
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].
* 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 java.io.IOException {
 
    throw new java.io.IOException("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: 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 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
 
Implementation: Use a Java agent to override the internals of ObjectInputStream to prevent exploitation of known dangerous types as seen in rO0 and NotSoSerial
 +
 +
 +
===Prevent Data Leakage===
 +
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===
 +
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");
 +
}</pre>
 +
 +
===Override ObjectInputStream#resolveClass()===
  
 
==Python==
 
==Python==
Line 33: Line 40:
 
==Ruby==
 
==Ruby==
  
 +
= 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 from being repurposed into malicious.
 +
 +
Many applications rely on a [https://en.wikipedia.org/wiki/Data_transfer_object data-transfer object pattern] that involves creating separate objects 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 =  
 
= References =  

Revision as of 16:33, 17 November 2015

DRAFT CHEAT SHEET - WORK IN PROGRESS

Introduction

This article is focused on providing clear, simple, actionable guidance for safely deserializing untrusted data in your applications.

What is Deserialization?

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.

Java

The following techniques are all good for preventing attacks against deserialization against 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. Implementation: Use a Java agent to override the internals of ObjectInputStream to prevent exploitation of known dangerous types as seen in rO0 and NotSoSerial


Prevent Data Leakage

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 the transient field.

Prevent Deserialization of Domain Objects

To guarantee that your application objects can't be deserialized, a readObject() should be declared (with a final modifier) which always throws an exception.

private final void readObject(ObjectInputStream in) throws java.io.IOException {
   throw new java.io.IOException("Cannot be deserialized");
}

Override ObjectInputStream#resolveClass()

Python

Ruby

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 from being repurposed into malicious.

Many applications rely on a data-transfer object pattern that involves creating separate objects 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

[1] [2]

Authors and Primary Editors

Arshan Dabirsiaghi - arshan [at] contrastsecurity dot org

Other Cheatsheets

OWASP Cheat Sheets Project Homepage


[[Category:Cheatsheets]]