CISSP Software Development Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Applying cryptographic integrity checks (e.g., HMAC) to serialized objects

  Why this is correct

  When serialized objects are transmitted or stored, an attacker might tamper with the serialized data to inject malicious code or alter object properties. Applying a cryptographic integrity check, such as a Hash-based Message Authentication Code (HMAC), to the serialized object ensures that any unauthorized modification to the data will be detected prior to deserialization. If the integrity check fails, the system can reject the object, preventing the execution of manipulated or malicious payloads embedded within the serialized stream. This effectively prevents the deserialization of tampered objects.

• ✗

  Implementing input validation on deserialized data

  Why it's wrong here

  Implementing input validation on data *after* it has been deserialized is insufficient to prevent deserialization attacks. Many deserialization vulnerabilities exploit the process itself, allowing malicious code to execute during the object's construction or method calls triggered by the deserializer, *before* any application-level validation logic can be applied to the resulting object's state. By the time validation occurs, the damage, such as remote code execution or arbitrary file writes, may have already been done, making this a reactive and often ineffective control against the core deserialization exploit.

• ✗

  Using a allowlist of classes allowed to be deserialized

  Why it's wrong here

  While using an allowlist of permitted classes for deserialization is a valuable security measure to prevent the instantiation of arbitrary or unexpected classes, it does not fully mitigate all deserialization vulnerabilities. Attackers can still exploit 'gadgets' within *allowlisted* classes, chaining their methods to achieve malicious outcomes like remote code execution or denial of service. The vulnerability often lies in the interaction and side effects of legitimate methods within trusted classes when invoked during deserialization with attacker-controlled data, rather than merely the presence of an unauthorized class.

• ✗

  Running deserialization in a sandboxed environment

  Why it's wrong here

  Running deserialization within a sandboxed environment can limit the *impact* of a successful deserialization attack by restricting the resources and permissions available to the deserialized object and its associated code. However, sandboxing does not *prevent* the initial exploitation or the execution of malicious code within the sandbox itself. An attacker could still achieve denial of service, information disclosure, or even sandbox escape if vulnerabilities exist, making it a containment strategy rather than a primary preventative measure against the deserialization vulnerability itself.

Go deeper

Related to this question