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.
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 means converting an object into 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.
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.
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:
The attacker changes the serialized object to give themselves admin privileges:
Thank you for reading my article
And if you like it give me a follow.