Back to Basics: Insecure Deserialization

Transmitting serialized data is fundamental to modern web applications, but can be tricky to implement securely. Malicious actors will attempt to exploit insecure uses of deserialization wherever they see serialized data being transmitted. In this post, we describe what insecure deserialization is, how this vulnerability is used to conduct cyber attacks, and how these attacks can be prevented – with secure coding best practices and protections built into the Fastly Next-Gen WAF.

What is Serialization?

Web applications often utilize complex data structures, and require a way to store or transmit that complex data from client to server (and vice versa). Serialization refers to the process of taking that complex data and converting it into a format that can be stored (e.g., within databases, files) or transmitted (e.g., across a network). Serialization is sometimes referred to by other names, such as marshalling, pickling, or flattening. Conceptually, it is similar to flattening moving boxes so you can fit them in your car and drive them over to your friend’s place.

Serialization is reversible, so the complex data can be reconstructed at a later time or in a different environment. The reverse process is called deserialization, and involves taking the serialized data and bringing it back into its complex state to be used again after storage or transmission.

There are many ways for data to undergo the serialization process and many formats that are used, depending on the use case for the data and the systems in question. Some formats are usable across different programming languages, like JSON or XML. Other serialization formats are specific to individual programming languages, like PHP or Java. Language-native serialization methods usually provide additional features compared to language-agnostic ones like JSON or XML. Unfortunately, these language-native mechanisms can introduce security vulnerabilities due to the additional features and assumptions about what serialized data will be provided.

What is Insecure Deserialization?

Insecure deserialization occurs when an application deserializes untrusted input, most often when using language-native serialization formats. Exploiting this relies mainly on two things:

1. Language-native serialization formats perform additional actions when deserializing data. Sometimes referred to as magic methods in PHP, they are actions that occur when complex data like Objects are reconstructed, destroyed, unserialized, etc. Sometimes this includes opening a file, creating a network connection, closing a socket, etc.

2. Lack of restrictions around what types of data will be deserialized.

The lack of restrictions in deserializing input can provide cyber attackers with a unique angle to introduce exploits. Attackers can rely on the additional actions taken by the application when data is deserialized to perform individual actions. Each one of those actions is colloquially referred to as a gadget. When an attacker combines multiple actions within a single payload, it’s referred to as a gadget chain. The trick for attackers is finding usable gadget chains. While the application may deserialize any input they provide, the application can’t just deserialize any arbitrary code. It has to understand the complex data after deserializing it in order for an exploit to work.

Think of this attack type like a microwave meal kit. You decide it's time for lunch, unpack the box, put the meal in your microwave, and turn it on. But what if an attacker put a whole bunch of aluminum inside that you didn't know about? Now your microwave is on fire! Now, instead imagine an attacker putting some rocks inside the microwave meal instead of aluminum. The rocks wouldn't damage your microwave. Maybe you’re confused and irritated because you didn't get to eat your meal and now have to throw it away and order some takeout, but nothing bad happened beyond some wasted time, resources, and frustration. In this case, the aluminum is a singleton gadget-chain that your microwave knows exactly what to do with – just with a bad outcome.

So how do attackers find aluminum to put inside your lunch? Gadget-chains can exist in arbitrary applications, but are frequently found within re-used libraries, which makes them portable for attackers to use across the web. Some examples of collections of these known gadget-chains include phpggc for PHP, Ysoserial for Java, and so on.

Insecure deserialization attacks can spiral out of control quickly depending on what gadgets are available or discovered within a vulnerable application. They go beyond simply tampering with a file to providing a launch pad for larger scale intrusions. Successful payloads may leak information, modify or delete files, or even enable arbitrary remote code execution (RCE). 

How to Prevent Insecure Deserialization Attacks

Given how common serialization is and how impactful an insecure deserialization vulnerability can be, secure coding practices are key for minimizing and mitigating risks. While the safest way to prevent insecure deserialization attacks is to never deserialize user-controlled input, that is likely not possible for many applications.

So, to minimize the risk of insecure deserialization attacks while still maintaining necessary application functionality, developer teams should consider the following prevention techniques:

• Review and document all potential serialization and deserialization mechanisms

• Reduce the deserialization of user-controlled input where possible to reduce the application’s attack surface

• Use less complex serialization formats (e.g., JSON) where possible to further reduce the application’s attack surface

• Use an allow-list approach to only deserialize inputs that match expected data types and prevent arbitrary trust of user input

• Implement procedures like strict signature verification to ensure data can be trusted

Audit error logs to analyze for potential serialization vulnerabilities. This is how we discovered CVE-2023-30534, an insecure deserialization vulnerability in Cacti.

As always, broader security best practices like defense-in-depth will add additional layers of protection when an inevitable vulnerability occurs. At the core of a robust application security strategy is a web application firewall (WAF) that keeps developers moving quickly without friction.

Prevent Deserialization Attacks with Fastly Next-Gen WAF

Fastly’s Fastly Next-Gen WAF is designed to detect insecure deserialization attacks by only signaling on malicious serialized inputs, without blocking the benign serialized data your application needs. Detecting malicious gadget-chains in PHP, Java, FastJSON, and more while still allowing normal usage of serialized input is key to protecting your application without impacting its performance. Contact us to learn more about how Fastly can help stop insecure deserialization attacks from derailing your applications.