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 major threat and can seriously harm businesses and customers. Potential vulnerabilities have been identified in the most popular programming languages, including Java, Python, .NET, PHP, Node.js, and Ruby.
What is Insecure Deserialization?
Insecure deserialization has been ranked #8 on the OWASP Top Ten List of web applications’ most critical security risks since 2019, 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.
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 into a format for saving it to a file or database or sending it via streams or networks. This basic function regularly needs to be performed for storing and transferring data. Programming languages serialize objects differently — 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 the serialized data from files, streams, or networks into objects. 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. Unsure deserialization should be avoided, in which malicious code comes from unauthorized user input.
This often happens when an attacker employs the customizable deserialization processes 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 many attacks 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. The application will deserialize the malicious input if there are no checks, 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. To make their code immutable, the programmers serialized user states, and passed back and forth with each request. An attacker abuses the “R00” Java object signature and performs remote code execution on the application server by employing the Java Serial Killer tool.
- 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";}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 what 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 only see your application’s “theoretical” view in a non-executed way.
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.
Insecure Deserialization Video Explanation
FAQs
When was the Insecure Deserialization vulnerability discovered?
The Insecure Deserialization Vulnerability was first reported on January 12th, 2019, by Tencent Security Xuanwu Lab researchers. This vulnerability allows attackers to execute arbitrary code on the target server when they can inject malicious data into the JSON string being passed to the deserialize method.
Which versions of PHP could be affected?
This vulnerability affects all versions of PHP 5.X and above. It has been patched for version 7.2.3 and later.
