OWASP Top 10: Insecure Deserialisation (A8:2017)

19th August 2020 ‧ By Simon Bell ‧ Category: Web Application Security

3 min read

Picture of a large box and a small box (to represent deserialisation)

This is part of the OWASP Top 10 series covering the top 10 most critical web application security risks. If you've missed any of the previous security risks, check out the intro and overview.

Risk rating

Exploitability: 1

Prevalence: 2

Detectability: 2

Technical: 3

Threat Agents	Exploitability	Weakness Prevalence	Weakness Detectability	Technical Impacts	Business Impacts
Application Specific	Easy: 3	Widespread: 3	Easy: 3	Severe: 3	Business Specific
	Average: 2	Common: 2	Average: 2	Moderate: 2
	Difficult: 1	Uncommon: 1	Difficult: 1	Minor: 1

OWASP's Risk Rating Methodology

What is insecure deserialisation?

Many web applications serialise and deserialise data -- a process that's useful for transforming data objects from the application into formats for other purposes, such as transferring over a network.

Think of serialising as a bit like when you move house. You pack all your items into boxes (serialising), transport the boxes via a removal company (transfer over a network), then unpack everything at the other end (deserialising).

An insecure deserialisation attack is like having the removal staff tamper with your contents before they arrive and get unpacked.

A web application might want to transfer one of its data objects (such as a customer object) to another service via API. The application does this by transforming its native data object into a serealisation format suitable for the API. The most common serealisation formats within web applications are JSON and XML.

Examples of insecure deserialisation

We saw an example of insecure deserialisation in the XML External Entities threat. Let's say an application deserialises XML data. The application receives the following XML:

<?xml version="1.0" encoding="ISO-8859-1"?>
  <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
  <foo>&xxe;</foo>

If the application is vulnerable to an XXE attack, then upon deserialising the XML data, the contents of /etc/passwd will be shown.

There are two main types of insecure deserialisation attacks:

Object and data structure attacks
Data tampering attacks

Object and data structure attacks

These types of insecure deserialisation attacks exploit the available classes of the underlying application. Such classes allow the attack to modify application logic or achieve remote code execution.

Data tampering attacks

These types of insecure deserialisation attacks leverage existing data structures, but modify the contents of the data.

What's the impact of insecure deserialisation?

There are many implications of insecure deserialisation attacks depending on the nature of the organisation and web application. The attacks can be very serious, such as resulting in remote code execution -- one of the most serious vulnerabilities whereby an attacker runs their own code with system-level privileges on the underlying server.

How to defend against insecure deserialisation

The most effective method to prevent insecure deserialisation attacks is to not process serialised data from untrusted sources or to use serealisation mediums that only permit primitive data types. However, in many cases, data from untrusted sources must be processed. There are numerous best-practices to mitigate insecure deserialisation from untrusted data sources.

Implement cryptographically strong integrity checks -- such as digital signatures -- on serialised data. This guarantees that data hasn't been altered in transit. However, it won't detect serialised data that was already malicious before being transferred.

Enforce strict type constraints when deserialising data to ensure objects have correctly defined classes. In addition, segregate deserialised code into an isolated environment with low privileges to mitigate any impact in case there's an attack.

Ensure sufficient logging and monitoring of the deserialisation process. Any errors, exceptions, or failures should be checked before allowing the deserialised code to run.