Insecure deserialization is a well-known, yet not commonly occurring, a vulnerability in which an attacker inserts malicious objects into a web application. This allows them to inflict denial-of-service (DoS) attacks, remote code execution attacks, SQL injections, Path Traversal, and Authentication Bypasses. 

Deserialization attacks are a major threat and can have serious consequences for businesses and their customers. Potential vulnerabilities have been identified for the most popular programming languages, including Java, Python, .NET, PHP, Node.js, and Ruby.

Insecure deserialization has been ranked as #8 on the OWASP Top Ten List of the most critical security risks to web applications since 2017, along with other risks such as an injection vulnerability. In addition, it’s recognized as one of the first steps that software development organizations need to take to ensure more secure coding.

Table of contents
  1. Insecure Deserialization Security Assessment Level
  2. The Basics About Serialization and Deserialization
  3. Examples of Insecure Deserialization Attacks
  4. How to Prevent Insecure Deserialization
  5. How to Test for Insecure Deserialization

Insecure Deserialization Security Assessment Level

Insecure Deserialization Security Assessment  Level

CVSS Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/CR:X/IR:X/AR:X/MAV:N/MAC:H/MPR:N/ MUI:N/MS:U/MC:H/MI:H/MA:H

The Basics About Serialization and Deserialization

Serialization and deserialization are common practices, and they’re used in web applications regularly. Many programming languages even have native tools for serialization. 

To create the best strategies for protecting your applications from insecure deserialization, it’s important first to introduce and understand these two concepts. 

Serialization

Serialization means converting an object in a format for saving it to a file or database or sending it via streams or networks. This is a basic function that regularly needs to be performed for storing and transfer of data. Programming languages serialize objects in different ways — using either binary or string formats. 

The data has to be shaped in a certain way — preprocessed to a byte stream — which is what serialization does. Some common serialization formats include XML and JSON. 

Deserialization

The deserialization processes are just the opposite of serialization. They entail converting into an object the serialized data from files, streams, or networks. Deserialization, essentially, reconstructs the byte stream in the very same state it was before being serialized. 

This conversion is a typical process when done securely. What should be avoided is insecure deserialization, in which malicious code comes from unauthorized user input. 

This often happens when an attacker employs the customizable deserialization processes that many programming languages offer to control them with untrusted input. Unfortunately, the languages presume the data is safe and treat all serialized data structures as validated, thus allowing the inclusion of malicious objects. 

Examples of Insecure Deserialization Attacks

Insecure deserialization attacks are often seen as difficult to execute and thus deemed not common, affecting as low as 1% of applications. Yet, due to the large volume of attacks that an application can be subject to, this type of attack shouldn’t be underestimated. 

The most typical example of an insecure deserialization vulnerability is when an attacker loads untrusted code into a serialized object, then forwards it to the web application. If there are no checks, the application will deserialize the malicious input, allowing it to access even more of its parts. That’s how it makes possible additional attacks that eventually may cause serious privacy vulnerability for the application’s user base. Insecure deserialization is thus sometimes referred to as an ‘object injection’ vulnerability.  

The OWASP Insecure Deserialization Cheat Sheet contains some common attack examples:

  • A set of Spring Boot microservices is called in a React application. The programmers serialized user states, which are passed back and forth with each request, to make their code immutable. An attacker abuses the “R00” Java object signature and by employing the Java Serial Killer tool, carries out remote code execution on the application server.
  • PHP object serialization is used for a PHP forum to save a “super” cookie loaded with data. It contains the user’s ID, role, password hash, and other states. An attacker modifies the serialized object to obtain admin privileges and tamper with the data. 
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

The attacker changes the serialized object to give themselves admin privileges:

a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Scan Your Web App for Insecure Deserialization Vulnerability

CHECK FOR FREE

How to Prevent Insecure Deserialization

To protect your web application from insecure deserialization, it’s crucial never to pass a serialized object manipulated with untrusted input by the user to the deserialize function. The reason is that if you do so, an untrusted user would be able to manipulate the object and can send it directly to the PHP deserialize function.

As an example how a serialized PHP object looks like, see the code block below:

O:9:"SomeClass":2:{s:20:"%00SomeClass%00file_name";N;s:16:"%00SomeClass%00value";N;}

If you need to pass serialized data between the web application and a user, you can use a secure and lightweight data-interchange format like JSON (JavaScript Object Notation) instead of unserializing.

The OWASP notes that the best way to prevent insecure deserialization attacks is never to accept serialized objects from untrusted users. Alternatively, you can use serialization tools that allow only primitive data types. 

In case you have to accept serialized objects, here are some tips for stopping insecure deserialization: 

  • Introduce digital signatures and other integrity checks to stop malicious object creation or other data interfering 
  • Run deserialization code in low privilege environments 
  • Keep a log with deserialization exceptions and failures
  • Execute strict constraints for the deserialization processes before object creation
  • Limit and check all incoming and outgoing network activity from deserialization containers and servers 
  • Keep tabs on deserialization activities to identify in case there is constant deserialization by a user 
  • Use deserialization methods like JSON, XML, and YAML that are language-agnostic 

How to Test for Insecure Deserialization

You can check your application manually from the source code site and in the running state for insecure deserialization testing.

You can also use a static code analysis tool. However, it would require access to your code and would only see your application’s “theoretical” view in a non-executed way.

If you want to test your executed, running application, the best approach is to use a dynamic application security testing tool. It can automatically scan your web application or API.

To test if your web application is vulnerable to insecure deserialization, you can run an invasive free scan through our Vulnerability Testing Software.

The content of this article is Creative Commons Attribution-ShareAlike v4.0.

See If Your Web App Or API Has Security Vulnerabilities

SCAN FOR FREE NOW