Insecure deserialization is a vulnerability that occurs when the data users can control is deserialized by a website. Deserialization is the process of extracting data from files, networks, or streams and rebuilding it as objects. It allows a website to interact with the user faster.
Insecure deserialization can allow attackers to manipulate serialized objects to insert harmful data into the application code, turning them malicious.
Other interesting terms…
Read More about “Insecure Deserialization”
Insecure deserialization is also known as an “object injection vulnerability.” That’s because threat actors replace a harmless object with a dangerous one during deserialization. Note that serialization and deserialization are required when computers interact with websites.
How Do Serialization and Deserialization Work?
Each time you browse a website, your browser serializes your requests to turn them into byte streams so the site can process them quickly. In response, the website’s server turns the file you requested, for instance, into byte streams or deserializes it to transform it into an object your browser can receive.
The key thing to remember is that serialization makes computer-to-server communication faster. But serialization won’t work without deserialization, which introduces vulnerabilities. Therein lies the problem.
Source: https://portswigger.net/web-security/images/deserialization-infographic.jpg
Why Do Insecure Deserialization Attacks Occur?
Many organizations suffer from insecure deserialization because they don’t understand how dangerous they can be. While some site owners may think adding checks to deserialized data is enough, they don’t realize its ineffectiveness. It is impossible to validate every instance. Checks also fail because they check the information after it has been deserialized, too late to prevent an attack.
There are other reasons, of course. But trust is often the culprit when it comes to weaknesses, including insecure deserialization vulnerabilities.
When Was the Insecure Deserialization Vulnerability Discovered?
Tencent researchers reported the first insecure deserialization vulnerability exploitation on 12 January 2019. It enabled attackers to execute arbitrary code on the target server after injecting malicious data into a JSON string they passed for deserialization. This vulnerability affected all versions of PHP 5.X and above but has been patched for version 7.2.3 and later.
What Are the Repercussions of Insecure Deserialization?
Insecure deserialization can lead to more damaging attacks, including:
- Remote code execution where attackers run a malicious code on a target server they don’t have physical access to
- Data tampering, where threat actors modify a target organization’s sensitive data
- Denial-of-service (DoS) attacks that can enable attackers to take target websites offline
What Are Examples of Insecure Deserialization Attacks?
The following table enumerates a few recent insecure deserialization attacks seen.
| Insecure Deserialization ID Number | Affected Application | What Attackers Can Do |
| CVE-2019-6503 | Chatopera cosin | Attackers can execute commands by uploading malicious files. |
| CVE-2019-10068 | Kentico | Threat actors can bypass the initial security header validation to execute malicious code remotely. |
| CVE-2018-7489 | FasterXML jackson-databind | Attackers can execute unauthenticated code remotely by bypassing a blacklist. |
| CVE-2018-6496 and CVE-2018-6497 | UCMBD Browser and UCMBD Server, respectively | Threat actors can perform a Remote Cross-Site Request Forgery (CSRF) attack. A CSRF attack exploits the trust a web application has in authenticated users the attackers are pretending to be. |
| CVE-2018-19362 | FasterXML jackson-databind | Attackers can prevent the user from using JBoss. |
| CVE-2018-1851 | Windows XP, Windows Server 2003, Windows Vista, Windows Server 2007, and Windows 7 | Threat actors can execute arbitrary code on target systems. |
| CVE-2017-9805 | Apache Struts | Attackers can execute malicious code remotely. |
How Can You Prevent Insecure Deserialization Attacks?
Because no one can tell if a deserialized object is safe to accept, meaning it doesn’t have harmful code built-in, it is best never to let your network accept serialized objects from untrusted sources.
Implementing additional integrity checks, such as ensuring serialized objects are digitally signed by the senders and validated by trusted certificate authorities (CAs) to prevent hostile object creation or data tampering, can also help.
If you can’t avoid deserialization, only allow it on systems and applications that don’t contain sensitive data. That way, if a deserialized object is used for an attack, it won’t affect the entire organization.
Also, use language-agnostic deserialization checks to cover all computer languages that attackers can use in their exploits.
—
While insecure deserialization attacks are hard to detect, they are still avoidable if you follow the best practices mentioned here.
