Insecure serialization has historically been seen as a super hard to grasp vulnerability, almost like a black box but while it does contain it’s challenges, so does every other issue type on the OWASP top 10. serialization is a technique used to convert an object into a byte stream for it to be stored somewhere or passed on to another system. As these serialized objects undergo deserialization, dangerous issues might arise. This issue is often referred to as “Marshalling” and “Unmarshalling”. Let’s have a look at this issue type from the Top 10 OWASP.
First we will need to get into Serialization, it is a process that occurs in applications when data needs to be transmitted and stored. This can be a very useful technique because two applications might have a completely different internal structure.
While objects might be serialized to store or transfer them, at some point they might need to be deserialized again. In this deserialization logic, vulnerabilities might reside. The biggest problem with this algorithm is that the deserialization process does not discriminate as it will deserialize any object that the application might have access to. The attacker might modify attributes of the object or even insert a new one entirely. The serialization process might leave the application vulnerable in a number of ways depending on the applications logic and the object that is serialized. We will look at a few examples but please know there are more ways to exploit this vulnerability.
One example, let’s say our object contains the attribute “isSuperUser:false”. An attacker might simply deserialize the object to change the attribute before serializing it again. The server will then take this new object and treat the user as a SuperUser. This is only one of the examples of how insecure deserialization can occur however.
we need to be aware that attackers might just as well add a parameter they suspect the server uses as a property for example, if the server does use isSuperUser as an attribute of the serialised object, it might still accept it when deserializing it.
For this example I want to bring up functionality that is meant to update a user's profile settings. As part of this functionality there exists a call to update a user's social media links. Normally the user can only specify the username part of the URI (for example in https://twitter.com/theXSSrat the user might normally only be able to edit the /theXSSrat part) but as part serialised object, the user can find the full URL.
After editing the URL to the users own attack servers they notice a request coming in which means a blind SSRF has been triggered by abusing business logic. This full URL should never be in the object in the first place and the attackers were able to abuse it.
We first of all need to start by explaining what a magic event is because that might not be clear to everyone. A magic event is a method in a programming language that gets called automatically. For example in PHP we have the following magic method: __sleep(). The problem with these magic methods is that they might be vulnerable to attacks if they handle data. This can happen through deserialized objects for example.
Besides the examples we have seen before, which rely heavily on insertion or adaptation of data, we can also insert arbitrary objects sometimes. This is possible because in object oriented programming, the methods that an object can access are delegated by it’s parent class. This means for example that normally, a user object has no access to the yet unreleased functionality to make a user admin. This resides on the URI /makeAdmin.php. The attacker can send a serialized object belonging to the class makeAdmin to a non expecting endpoint to change their profile picture which also expects a serialized object. The problem is that for deserialization the code does not care about what object is passed to it. It will happily deserialize it and while it may cause an error due to unexpected parameters, the damage is done and the user made themselves admin.
We have already looked at a few examples but these can all be brought under one of three types of Insecure Deserialization.