Skip to main content

Prevent insecure deserialization attacks

Insecure Deserialization is an attack where a manipulated object is injected into the context of the web application.

Security assessment

Security_Assessment_InsecureDeserialization

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

Vulnerability information

Insecure deserialization is a well-known yet not commonly occurring 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 significant threat and can have severe consequences for businesses and customers. Potential vulnerabilities have been identified in 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 web applications most critical security risks since 2017, along with other risks such as an injection vulnerability. In addition, it is recognized as one of the first steps that software development organizations need to take to ensure more secure coding.

Attack examples

Insecure deserialization attacks are often seen as challenging to execute and thus deemed not typical, affecting as low as 1% of applications. Yet, due to a large number of attacks, an application that can be subject to this 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 and then forwards it to the web application. The application will deserialize the malicious input if there are no checks, allowing it to access even more of its parts. That is 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. To make their code immutable, the programmers serialized user states, which are passed back and forth with each request. An attacker abuses the R00 Java object signature and, by employing the Java Serial Killer tool, performs 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 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";}

Prevent attacks

To protect your web application from insecure deserialization, it is 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:

Insecure_Deserialization_Code

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

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.

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 only see the "theoretical" view of your application 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 the Vulnerability Testing Software.

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