Wesley is an incident handler in a company named Maddison Tech. One day, he was learning techniques for eradicating the insecure deserialization…

Question breakdown

Tests

Eradicating insecure deserialization vulnerabilities

Difficulty

Medium

Key idea: Defending against insecure deserialization means limiting what can be serialized and deserialized, so security-sensitive classes should never be serializable.

How to reach the answer

1. The question asks which practice Wesley should avoid, so look for the option that weakens security.
2. Allowing serialization of security-sensitive classes exposes their internal state to tampering and leakage.
3. Validating untrusted input and understanding serialization permissions are standard recommended controls.
4. Option A is phrased awkwardly, but it reflects the trust-boundary guidance in EC-Council's material, so C is the answer to avoid.

Each option

• AIncorrect. This trust-boundary consideration appears in EC-Council's list of recommended practices, so it is not the one to avoid.
• BIncorrect. Understanding the security permissions granted to serialization and deserialization is a recommended control.
• CCorrect. Allowing security-sensitive classes to be serialized is a bad practice, because it lets attackers read or manipulate sensitive object state.
• DIncorrect. Validating input to ensure serialized data contains only trusted classes is a recommended defense.

Common trap: The odd wording of option A ('trusted data must cross a trust boundary') looks wrong, which can pull candidates away from the clearly insecure option C.

In practice: In Java and .NET applications, teams mark sensitive classes non-serializable and use allow-lists of classes during deserialization. These controls block gadget-chain remote code execution.

Remember: Never allow security-sensitive classes to be serialized, and restrict deserialization to allow-listed trusted classes.

Drafted with AI assistance and checked against the answer key.