Introduction

Web applications are no longer what they were in the early 2000s. They have evolved into something quite different. In addition, they have the ability to store and analyse complicated data structures. Although this has increased complexity, it has also increased the possibility of unthinkable consequences if not handled appropriately.

This will eventually result in privilege escalation, which will almost always compromise user data, resulting in the loss of the organisation’s reputation and financial resources. One of the vulnerabilities that we’ll be discussing is insecure deserialization.

Insecure deserialization, which once held the 8th spot in the OWASP top 10 vulnerabilities, has now been clubbed with other vulnerabilities and renamed Software and Data Integrity Failures.

What are deserialization vulnerabilities, and why does it occur?

How do you think web applications process, store, and transfer data objects?

For example, consider a scenario in which an application has a number of different roles, and the application wishes to manage both authentication and authorization in the same session cookie or parameter to tackle two difficulties simultaneously. This means that there is no need to do time-consuming operations such as retrieving rights from the session ID issued to the user; instead, you can simply retrieve the role from the cookie or header and assign specific permissions to the user as a result of that and the user tracking will be easy as well?

Let’s discuss it in detail.

There are a lot of different attributes that will be assigned to the user with the session id, such as

1. username
2. profile_picture
3. Role

When you log in to the application, what gets transferred or saved on the disk is the serialized form of this object.

What is Serialization?

The conversion of the object into a byte stream or a flat structure is called serialization. This “byte stream” is also a flatter version of the object. This can now be sent across networks and saved on disks, files, and databases. But how does this byte stream convert back to the object, so that we access the application again with the same permissions?

Deserialization

In a programming language, deserialization refers to converting a data stream into an object. Now that it has been restored to its former state, you can resume working on the application at your convenience.

But how is this a vulnerability?

This can be a vulnerability if the attacker tampers with the byte stream and the application deserializes it directly. This can lead to the escalation of privileges, information disclosures, and even remote code execution.

Exploitation Scenarios

Consider a dynamic web application that has user roles defined. By default, if any user registers an account, he’ll get a non-admin user account. Suppose you register an account with the username ronald. The web application generates a serialized object and then assigns this as a cookie to the user. This content is base64 encoded.

Tzo0OiJVc2VyIjoyOntzOjg6InVzZXJuYW1lIjtzOjY6InJvbmFsZCI7czo2OiJzdGF0dXMiO3M6OToibm90IGFkbWluIjt9Cg==

Since this is base64 encoded, on decoding, we get:

O:4:”User”:2:{s:8:”username”;s:6:”ronald”;s:6:”status”;s:9:”not admin”;}

A closer look at the cookie reveals that the object’s name is “User” and it has 2 fields, username, and status, as we can see that our username is ronald and our status is not admin. (s:9 refers that “not admin” is a string and its length is 9).

If we were to change not admin to admin and s:9 to s:5 (as the length of admin is 5 characters), we get the following:

O:4:”User”:2:{s:8:”username”;s:6:”ronald”;s:6:”status”;s:5:”admin”;}

Base64 encoding it, we get:

Tzo0OiJVc2VyIjoyOntzOjg6InVzZXJuYW1lIjtzOjY6InJvbmFsZCI7czo2OiJzdGF0dXMiO3M6NToiYWRtaW4iO30K

Once we replace the cookie with our tampered cookie, the web application will deserialize it and end up giving us admin access.

Remediation

These vulnerabilities arise because the server directly executes or parses the input from the client. An attacker can easily exploit the trust that a server has for the client and the user.

Some of the remediation mechanisms that can be applied are:

1. User input should be avoided unless necessary.
2. Cookies and other serialized objects must be signed to prevent them from being tampered with.

Conclusion

Serialization of complex data structures for data storage and transmission is necessary. This helps to reduce the bandwidth and makes storage and transmission easy, and prevent errors. But if the server deserializes everything provided to it, without validating and verifying if the input was tampered with, it can lead to server impacts. Insecure deserialization issues are quite common in php, python, and Java. Developers should ensure that safe functions are used, and necessary precautions are taken to prevent insecure deserialization.