R321. Avoid deserializing untrusted data

Requirement

The system must not deserialize untrusted data before applying the appropriate integrity checks.

Description

Serialization is the process of transforming an object into a stream of bytes to store or transmit it. This allows saving its state, so that it can be recovered later using deserialization. If an object comes from an untrusted source and it is not properly validated before being deserialized, it can lead to deserialization attacks such as object injection.

References

  1. CAPEC-130: Excessive Allocation. An adversary causes the target to allocate excessive resources to servicing the attackers' request, thereby reducing the resources available for legitimate services and degrading or denying services. Usually, this attack focuses on memory allocation, but any finite resource on the target could be the attacked, including bandwidth, processing cycles, or other resources.

  2. CAPEC-153: Input Data Manipulation. An attacker exploits a weakness in input validation by controlling the format, structure, and composition of data to an input-processing interface. By supplying input of a non-standard or unexpected form an attacker can adversely impact the security of the target.

  3. CAPEC-248: Command Injection. An adversary looking to execute a command of their choosing, injects new items into an existing command thus modifying interpretation away from what was intended.

  4. CAPEC-586: Object Injection. An adversary attempts to exploit an application by injecting additional, malicious content during its processing of serialized objects.

  5. CWE-94: Code Injection. The software constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

  6. CWE-95: Eval Injection. The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g., "eval").

  7. CWE-502: Deserialization of Untrusted Data The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid.

  8. OWASP Top 10 A1:2017-Injection. Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

  9. OWASP Top 10 A4:2017-XML External Entities (XXE). Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.

  10. OWASP Top 10 A8:2017-Insecure Deserialization. Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

  11. OWASP-ASVS v4.0.1 V1.5 Input and Output Architectural Requirements.(1.5.2) 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.

  12. OWASP-ASVS v4.0.1 V5.5 Deserialization Prevention Requirements.(5.5.1) Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering.

  13. OWASP-ASVS v4.0.1 V5.5 Deserialization Prevention Requirements.(5.5.3) Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers).

  14. OWASP-ASVS v4.0.1 V5.5 Deserialization Prevention Requirements.(5.5.4) Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval() to parse JSON.

  15. OWASP-ASVS v4.0.1 V13.2 RESTful Web Service Verification Requirements.(13.2.2) Verify that JSON schema validation is in place and verified before accepting input.

  16. OWASP-ASVS v4.0.1 V13.3 SOAP Web Service Verification Requirements.(13.3.1) Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place.

  17. PCI DSS v3.2.1 - Requirement 6.5.1 Address common coding vulnerabilities in software-development processes such as injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.

Copyright © 2020 Fluid Attacks, We hack your software. All rights reserved.

Service status - Terms of Use - Privacy Policy - Cookie Policy