Link Search Menu Expand Document

Unsafe Deserialization

  1. Unsafe Deserialization
    1. Description
    2. Impact
    3. Prevention
    4. Testing

image

Description

Unsafe Deserialization (also referred to as Insecure Deserialization) is a vulnerability wherein malformed and untrusted data input is used to compromise an application’s logic, resulting in a denial of service or even arbitrary code execution once the input is deserialized. Although this isn’t exactly a simple attack to employ, it featured in OWASP’s Top 10 most recent iteration due to the severity of impact upon compromise.

The process of converting an object state or data structure into a storable or transmissible format is called serialization. Deserialization is its opposite - the process of extracting the serialized data to reconstruct the original object version.

Unsafe Deserialization issues arise when an attacker is able to pass ad-hoc malicious data into user-supplied data to be deserialized. This could result in arbitrary object injection into the application that might influence the correct target behavior.

Impact

A successful Unsafe Deserialization attack can result in the full compromise of the confidentiality, integrity, and availability of the target system, and the oft-cited Equifax breach is probably the best example of the worst outcome that can arise. In Equifax’s case, an unsafe Java deserialization attack leveraging the Struts 2 framework resulted in remote code execution, which, in turn, led to the largest data breach in history.

Prevention

It is important to consider any development project from an architectural standpoint to determine when and where serialization is necessary. If it is unnecessary, consider using a simpler format when passing data.

In cases where it is impossible to forego serialization without disrupting the application’s operational integrity, developers can implement a range of defence-in-depth measures to mitigate the chances of being exploited.

  • Use serialization that only permits primitive data types.
  • Use a serialization library that provides cryptographic signature and encryption features to ensure serialized data are obtained untainted.
  • Authenticate before deserializing.
  • Use low privilege environments to isolate and run code that deserializes.

Finally, if possible, replace object serialization with data-only serialization formats, such as JSON.

Testing

Verify that serialization is not used when communicating with untrusted clients. If this is not possible, ensure that adequate integrity controls (and possibly encryption if sensitive data is sent) are enforced to prevent deserialization attacks including object injection.


Table of contents