The threat of insecure deserialization has only recently been added to OWASP as a result of surveys with security researchers and increased reports of this attack vector being leveraged by hackers. Before we can understand what the attack is, we need to first look at how serialization within an application works, and how it ties in with insecure deserialization.
What is serialization?
Serialization is the process of turning an object into a data format or byte stream that can be restored at a later time. It is done to allow data to be stored or transmitted in a serial format. Deserialization takes this serialized data and transforms it back into a data object. It is useful because it can preserve the state of an object prior to it being serialized and transmitted or stored, meaning that application developers have an efficient method of preserving object states.
JSON (JavaScript Object Notation) is currently the most popular format in use within web applications – hence the popularity of this attack and the increasing likelihood that the vulnerability will be exploited in the future if not properly protected against. Previously, XML formed the basis of web application attacks but, as newer designs are more frequently using JSON, attention needs to be put on insecure deserialization as an urgent security matter. The vulnerability takes many different forms, so there are multiple attack angles that the hostile intruder can take. This means that a lot of the advice given to developers and security experts can sound somewhat generalized. Specific functions within a web application will need to be scrutinized closely if there are any concerns that this vulnerability could affect one of your live systems. Injecting hostile serialized objects into a web app to initialize unauthorized deserialization can effectively get a web application to run a malicious script or program that will allow the attacker to gain access to the webserver, or cause damage to it and the web applications and services that are hosted on the platform. Once the malicious code has been executed, the angle of the attack can then change, depending on what the attacker is planning on achieving. Insecure deserialization can therefore be thought of as an entry point into a system, which means that wherever it occurs there is the potential for unauthorized access to your online platform.
Some solutions
While some of these suggestions may sound a little generalized, it is important to think about your own environment and how you could apply such measures in order to protect your organization from such attacks. Not all of these will apply to your particular situation, but it is always a good idea to look at as many potential openings in your defenses as possible if you are to try to fully protect your systems from an intrusion.
Do Not Accept Serialized Objects from Untrusted Sources
This is where authentication and basic security need to be implemented in your application or environment. By allowing only authenticated users and processes to have access to your web app, you are able to minimize the chances of your system falling prey to such an exploit. This does not solve the issue entirely, though, because accounts can be hacked and access can be gained through other malicious avenues, but it is a good place to start.
The Serialization Process Needs to Be Encrypted So That Hostile Object Creation and Data Tampering Cannot Run
Implementing this change will require some revamping of your application but, because it has a good chance of circumventing this vulnerability, you will need to weigh your options and decide whether or not this can be implemented on your project.
Run the Deserialization Code with Limited Access Permissions
If a desterilized hostile object tries to initiate a system processes or access a resource within the server or the host’s OS, it will be denied access and a permission flag will be raised so that a system administrator is made aware of any anomalous activity on the server.
Strengthen Your Code’s java.io.ObjectInputStream
This suggestion comes from the OWASP Cheat Sheet, and demonstrates how the input section of the code can be hardened to make unauthorized code difficult to run. The code below shows how the bicycle class is the only class that is allowed to deserialize. In this way, you can manage your code and lock down unauthorized deserialization.
Monitoring the Serialization Process Can Help Catch Any Malicious Code and Breach Attempts
This is another way of checking what is being deserialized in real time, or by keeping a log file of the activity for analysis at a later stage if any malicious activity is detected on the application.
Validate User Input
This is important, especially when input is processed through serialized data streams. Malicious users are able to use objects like cookies to insert malicious information to change user roles. In some cases, hackers are able to elevate their privileges to administrator rights by using a pre-existing or cached password hash from a previous session. From here, attackers can launch DDOS attacks, remote execution of malicious files, and anything else that they want to run from your server.
Use a Web Application Firewall That Can Detect Malicious or Unauthorized Insecure Deserialization
A WAF is either a hardware appliance, a piece of software like a plugin, or a predefined filter that monitors internal HTTP traffic and blocks predefined attacks such as SQL injections, cross-site scripting, and insecure deserialization attempts.
Prevent Deserialization of Domain Objects
Sometimes application objects are made to implement serializable because of the hierarchy structure of the program or application. To make sure that the application’s objects are not able to be deserialized, as suggested by the OWASP Insecure Deserialization Cheat Sheet, something like a readObject() should be declared (with a final modifier), which always throws an exception. Below is the sample code given by OWASP in the same article.
Use Non-Standard Data Formats
By using non-standard data formats, you lessen the chances of being susceptible to insecure deserialization. This is because your attacker in unlikely to know what methods you have used within the code without first having to review it. This can frustrate an attacker and make you a more difficult target.
Only Deserialize Signed Data
This is another effective method for your web app to bypass any data that has not been digitally signed. If your application has a work queue with anticipated signed commands that need to be deserialized, it can ignore any data that comes down the pipe without a valid signature. A flag can also be set up so that you are notified of any strange behavior from your app, allowing you to analyze any recent activity in your application. Plugging these holes will require human intervention and manual code scrubbing and can be quite labor-intensive, but these steps are necessary to combat the growing exploitation of insecure deserialization. Not all of these solutions can be implemented in every scenario but, with enough awareness of the issue, you can start to formulate a strategy that will protect your web app from malicious activity from the internet.
Useful Resources
Deserialization Cheat Sheet What is insecure deserialization OWASP top 10 Insecure deserialization What is insecure deserialization What is insecure deserialization – Acunetix
