Which of the following is not a common example of insecure deserialization Prevention

Update: Insecure Deserialization is proposed to move into a new category in the OWASP Top 10 2021 called Software and Data Integrity Failures. 

Insecure Deserialization is one of the vulnerabilities on OWASP‘s Top 10 list and allows attackers to transfer a payload using serialized objects. This happens when integrity checks are not in place and deserialized data is not sanitized or validated. A proof of concept video follows this article. OWASP is a non-profit organization with the goal of improving the security of software and the internet. We cover their list of the ten most common vulnerabilities one by one in our OWASP Top 10 blog series. 

Description

Developing a web application sometimes requires you to transfer an object. In simple terms, the object contains a bunch of variables that in turn contain information. However, an object cannot be transferred directly, so it has be converted into something else first.

This conversion is called serialization. Serialization is the process of taking an object and translating it into plaintext. This plaintext can then be encrypted or signed, as well as simply used the way it is. The reverse process is called deserialization, i.e. when the plaintext is converted back to an object.

In the most simple use case it is possible to just JSON-encode all the data in the object and use it as it is. Even when developers know that user input is not to be trusted, serialized objects are seen as something different and the security mindset is forgotten. In these scenarios, Insecure Deserialization is just another way of sending the payload which then affects an underlying vulnerability.

In many languages, there are native implementations of serialization that are more flexible. It might be possible to overwrite existing variables, or define what should be done if it is not possible to deserialize. In the case of compiled source code, it might be possible for an attacker to replace the code that will be executed on the server and thus achieve remote code execution.

Prevalence

Insecure deserialization got on the OWASP top 10 based on survey data, not quantifiable data. As such, it is hard to say just how common it is.

As more and more developers start to recognise this vulnerability type and more security tools support it, it is believed more vulnerabilities caused by insecure deserialization will be found. For now, we do not really know more than that these vulnerabilities are often found in big popular applications and it is not rare for the vulnerable code to have been there for a long time.

Potential impact

The impact depends on how the serialized object is used. Remote code execution or remote command execution, that would be considered the most critical, is absolutely a possibility given the circumstances.

In many cases Insecure Deserialisation is just a way of transferring the payload, which then affects another vulnerability, making it hard to classify the general impact.

Well-known events

One of the most widely discussed hacks in 2017 was the Equifax hack. The hackers are believed to have exploited a Struts vulnerability  that is based on insecure deserialization.

How to discover Insecure Deserialization

Look at all deserializations.

1. Is any of the data from there on handled as trusted internal data, or is it correctly handled as user input? That would, for example, mean proper sanitisation before the deserialized data is used.

2. Is the data validated to actually be what is expected before being used? If a string is expected, make sure that a string and not an integer is received before the application continues.

Read up on the functions used for deserialization. The documentation often has security warnings about common mistakes. In several frameworks, there are multiple functions that can be used for serialization/deserialization and depending on the context it is important to choose the right one.

Exploitability

Manual work is often needed to exploit this issue, which makes it less likely to be abused through automated attacks. However, if an exploit is once compiled towards one system, it can be automated towards all other systems running the same applications.

If the attacker has access to the source code of an application, finding this vulnerability is well above average in difficulty. However, it is absolutely not complex enough to be considered impossible to find even for less experienced attackers.

How Detectify can help

Detectify primarily checks for components that are known to be vulnerable to Insecure Deserialization. There are some additional tests, but as mentioned above, many attacks would require manual intervention to exploit, something automated tools such as Detectify cannot do. We recommend running regular security scans to keep an eye on vulnerable components.

Code example of a vulnerable application

JavaScript

gameState = {
    username = "Gamer42",
    score = 1445,
    timeSpent = "00:43:01"
}

serialized = JSON.stringify(gameState)
// 'serialized' is now a string that can be sent over the internet

deserialized = JSON.parse(serialized)
// 'deserialized' is now the same as 'gameState'

document.getElementById("score").innerHTML = deserialized.score;
// if the attacker controls the 'serialized'-variable, this would lead to XSS

Python

import os
import pickle

# create an object that should be serialized
class Exploit(object):
	def __reduce__(self):
		return (os.system, ('whoami',))

# load the exploit into a string
# this is what is called the serialized object
serialized = pickle.dumps(Exploit())

# this string/serialized object could now be sent over the internet

# deseralize and execute the code
pickle.loads(serialized)

# if the attacker can modify the serialized-variable, this would lead to remote code execution

Remediation

• Do not trust user input. This has always been true, and remains so even if input comes in the form of a serialized object.
• Validate the data before using it. If you expect a number, make sure it is indeed only a number before using it.
• If you are sending the object between two trusted systems (eg., storing it on the client), make sure the object has not been modified. This could be done with a checksum or digital signatures.
• Read up on the function used for deserialization. It is possible there are more secure variations available, something that is often mentioned in the official documentation.
• If all of this appears confusing, maybe there is no need to use serialization at all. You can often achieve the same results using a different approach.

Insecure Deserialization Proof of Concept video:

Read more

OWASP

Insecure Deserialization

Which of the following is common example of insecure deserialization prevention?

Which of the following are ways of preventing insecure deserialization?

What type of attack is possible through insecure deserialization?

Which of the following scenarios is most susceptible to an insecure deserialization attack?