Skip to content

Insecure Object Serialization

Insecure Object Serialization

Description

The application uses an insecure deserialization scheme from untrusted data.

Insecure object deserialization may result in

  • Arbitrary remote code execution
  • Modification of the application logic
  • Data tampering, such as bypassing access control

The exploitation of deserialization vulnerabilities is difficult due to the absence of off-the-shelf exploits and the need to tweak them for the targeted exploit.

Recommendation

To prevent object serialization vulnerabilities, the application must either:

  • Accept serialized objects from trusted sources only
  • Use serialization primitive data types only

If these measures are not possible, consider the following:

  • Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering.
  • Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes. However, bypasses to this technique have been demonstrated, so reliance solely on this is not advisable.
  • Isolating and running code that deserializes in low privilege environments when possible.
  • Logging deserialization exceptions and failures, such as where the incoming type is not the expected type or the deserialization throws exceptions.
  • Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.
  • Monitoring deserialization, alerting if a user deserializes constantly.

Standards

  • CWE_TOP_25:
    • CWE_502
  • OWASP_ASVS_L1:
    • V5_5_1
    • V5_5_3
  • OWASP_ASVS_L2:
    • V1_5_2
    • V5_5_1
    • V5_5_3
  • OWASP_ASVS_L3:
    • V1_5_2
    • V5_5_1
    • V5_5_3
  • PCI_STANDARDS:
    • REQ_2_2
    • REQ_6_2
    • REQ_6_3
    • REQ_6_4
    • REQ_11_3
  • SOC2_CONTROLS:
    • CC_2_1
    • CC_4_1
    • CC_7_1
    • CC_7_2
    • CC_7_4
    • CC_7_5