Les codeurs conquièrent la sécurité : série Share & Learn - Désérialisation non sécurisée

Depending on the application, the process of serialization can happen all the time. It's the term used to describe whenever data structures or object states are translated into a format that can be stored or possibly sent as a communication. Deserialization is the opposite of this process, taking the now structured data and turning it back into the object or data string that it was before storage.

Insecure deserialization can happen whenever an application treats data being deserialized as trusted. If a user is able to modify the newly reconstructed data, they can perform all kinds of malicious activities such as code injections, denial of service attacks or simply changing the data to give themselves some advantage within the application like lowering the price of an object or elevating their privileges.

In this episode we will learn:

• How attackers can exploit insecure deserialization
• Why insecure deserialization is dangerous
• Techniques that can fix this vulnerability.

How do Attackers Exploit Insecure Deserialization?

These days, the most popular data format for serializing data is JSON, though XML is a close second. Quite a few programming languages also offer their own methods for serializing data which often contains more features than JSON or XML. In any case, problems can occur if developers program apps to treat deserialized data as trusted input, as opposed to following the old mantra from other blogs in this series, specifically: "Never trust user input!"

User input is never to be trusted because the user can insert code into those strings, which might accidentally be executed by the receiving server. And since raw deserialized data can also sometimes be accessed and exploited, it needs to fall into that same untrusted category.

For example, if a forum application uses PHP object serialization to save a cookie containing a user's identification and role, then that can be manipulated. A malicious user might change their "user" role to "admin" instead. Or, they can use the opening provided by the data string to inject code, which might be misinterpreted and run by the server as it processes the "trusted" data.

Why is Insecure Deserialization Dangerous?

It's true that this kind of attack requires some modicum of skill on the part of a hacker, and sometimes trial and error while the attacker learns what kinds of code or exploits the server will accept from their manipulated, deserialized data. That said, this is a commonly exploited vulnerability because of the potential power it gives to hackers skilled enough to use it.

Depending on how the deserialized data is supposed to be used, any number of attacks, including many that we covered in previous blogs, can be employed. Insecure deserialization can be a gateway to remote cross-code injection, cross-site scripting, denial of service, access control hijacking, and of course SQL and XML injection attacks. It basically opens up a launching point, declares all the data being deserialized to be trusted, and lets the attackers try and exploit it.

Eliminating Insecure Deserialization

The safest thing that organizations can do to prevent insecure deserialization is to restrict applications from accepting deserialized data. That may not be possible or realistic however, but no worries, because there are other techniques that can be employed to defend against this kind of attack.

If possible, data can be sanitized to something like numeric values. This might not totally stop an exploit, but would prevent code injections from occurring. Even better is simply requiring some form of integrity check against deserialized data such as a digital signature, which could ensure that data strings have not been manipulated. And all deserialization processes should be isolated and run in a low privilege environment.

Once you have those protections in place, be sure to log all failed deserialization attempts, as well as network activity coming from containers or servers that deserialize data. If a user triggers more than a couple of deserialization errors in the logs, it's a good indication that they are either a malicious insider or have had their credentials hacked or stolen. You might even consider things like automatic lockouts for users that constantly trigger deserialization errors.

Whichever of these tools you employ to fight insecure deserialization, remember that at the core, this is data that might have been touched or manipulated by a user. Never trust it.

More Information about Using Components with Known Vulnerabilities

For further reading, you can take a look at what OWASP says about insecure deserialization. You can also put your newfound defensive knowledge to the test with the free showcase of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.