A8 2017 – Insecure Deserlization

The serialization is the process of turning some objects into a data format that can be restored later. For example, you have a forum, online shop or any other web site and you have to send objects between different parts of this site. So, during the serialization you transform an object to a byte stream, so it was in a right form to traverse around HTTP traffic or send to be stored in database.

So, the deserialization is the exact opposite process in which we take structured data from some format and rebuild it to an object.

Most poplar thing today is JSON (JavaScript Object Notation), while recently it was XML, which we discussed in A4.

So, what can go wrong, why is that a problem?
a8-1

Well, basically it’s a case of an unvalidated user input that we’ve discussed previously in this series. But this time it travels around our application and might corrupt data.

Let’s say we have an e-shop written in php. And we want to store a user cookie data that contains useful information like user ID, his permissions and contents of his shopping cart. User Anna’s cookie might look like:

anna:guest:N1N2N10

But then an attacker comes in, he can insert some malicious data in his cookie that will be deserialized later:

eve:admin:N1N2N10

Here we’re not adding something directly to a web page but instead we’re using web site logic to collect our malicious data. This data can trigger a remote code execution or a denial of services attack (server might hangup trying to deserialize what you’re feeding to it),

Unfortunately, there’s no example for this in OWASP Mutillidae because this vulnerability is relatively new to OWASP TOP 10 list I think.

I must mention that this vulnerability is difficult to find since this “door” is so narrow. But even so countermeasures are pretty much the same though:

  • Review a code to find breach points. In fact, there can be not too many of them.
  • Do not access unvalidated data from untrusted sources. Speaks for itself.
  • Encrypt serialization process. This way data won’t be tampered in process.
  • Run deserialization code with limited permission. It might help during testing and later.
  • Use Web Application firewall.

a8-2

This vulnerability can take many different forms and shapes and range of attacks is wide. So all these advices are really general and can be applied for the whole vulnerability management process.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s