Insecure Deserialization is an attack where a manipulated object is injected into the context of the web application.
Insecure Deserialization is an attack where a manipulated object is injected into the context of the web application. If the application is vulnerable, the object is deserialized and executed, which can result in SQL Injection, Path Traversal, Application Denial of Service and Remote Code Execution.
In order to protect your web application from this type of vulnerability, you should never pass a serialized object, which can be manipulated by the user, to the deserialize function. Instead of unserialize you could use a secure data interchange like JSON if you need to pass serialized data between the user and the web application.
As an Example how a serialized PHP object looks like, see the code block below:
The insecure deserialization vulnerability could be triggered if an untrusted user is able to manipulate the object and can send it directly to the PHP unserialized function.
How to Prevent Insecure Deserialization
The OWASP Cheat Sheet for Insecure Deserialization states the following aspects on how to prevent Insecure Deserialization.The only safe architectural pattern is not to accept serialized objects from untrusted sources or to use serialization mediums that only permit primitive data types. If that is not possible, consider one of more of the following:
- Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering.
- Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes. Bypasses to this technique have been demonstrated, so reliance solely on this is not advisable.
- Isolating and running code that deserializes in low privilege environments when possible.
- Log deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions.
- Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.
- Monitoring deserialization, alerting if a user deserializes constantly.
Example Attack Scenarios for Insecure Deserialization
The OWASP Cheat Sheet for Insecure Deserialization also contains the following two attack examples:
Scenario #1: A React application calls a set of Spring Boot microservices. Being functional programmers, they tried to ensure that their code is immutable. The solution they came up with is serializing user state and passing it back and forth with each request. An attacker notices the “R00” Java object signature, and uses the Java Serial Killer tool to gain remote code execution on the application server.
Scenario #2: A PHP forum uses PHP object serialization to save a “super” cookie, containing the user’s user ID, role, password hash, and other state:
An attacker changes the serialized object to give themselves admin privileges:
How to test for Insecure Deserialization
For insecure deserialization testing, you can of course go through the examples mentioned above and check your application manually - both from the source code site, as well as in the running state.
You could also use a static code analysis tool, which 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, we recommend a dynamic application security testing tool to automatically scan your web application or API.
To test if your specific application is vulnerable for insecure deserialization, run an invasive scan in our Vulnerability Testing Software for free.
The content on this article is Creative Commons Attribution-ShareAlike v4.0.