The serialization and deserialization features can be exploited to bypass security manager checks. A serializable class may employ security manager checks in its constructors for various reasons. For example, the checks prevent an attacker untrusted code from modifying the internal state of the class.
Security manager checks must be replicated at all points where a class can be constructed. Because deserialization acts like a constructor, all the relevant methods must contain a security check.
If the class enables a caller to retrieve sensitive internal state contingent upon security checks, the same checks must be replicated during deserialization. This ensures that an attacker cannot glean sensitive information by serializing the object.
Noncompliant Code Example
In this noncompliant code example, security manager checks are used within the constructor but are not replicated within the readObject
and writeObject
writeObject()
and readObject()
methods that are used in the serialization-deserialization process. This allows an attacker untrusted code to maliciously create instances of the class that bypass security manager checks when deserialization is performed.
Code Block | ||
---|---|---|
| ||
import java.io.Serializable; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; public final class CreditCard implements Serializable { //private internal state private String credit_card; private static final String DEFAULT = "DEFAULT"; public CreditCard() { //initialize credit_card to default value credit_card = DEFAULT; } //allows callers to modify (private) internal state public void changeCC(String newCC) { if (credit_card.equals(newCC)) { // no change return; } else { validateInput(newCC); credit_card = newCC; } } // readObject correctly enforces checks during deserialization private void readObject(ObjectInputStream in) { in.defaultReadObject(); // if the deserialized name does not match the default value normally // created at construction time, duplicate the checks if (!DEFAULT.equals(credit_card)) { validateInput(credit_card); } } // allows callers to retrieve internal state public String getValue() { return somePublicValue; } // writeObject correctly enforces checks during serialization private void writeObject(ObjectOutputStream out) { out.writeObject(credit_card); } } |
Compliant Solution
The This compliant solution correctly implements the required security manager checks in all constructors , and methods that can either modify internal state and methods that or retrieve internal state. As a result, an attacker cannot create an a modified instance of the object with modified state (using deserialization) or read the serialized byte stream to uncover sensitive serialized data (using serialization).
Code Block | ||
---|---|---|
| ||
import java.io.Serializable; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; public final class SecureCreditCard implements Serializable { //private internal state private String credit_card; private static final String DEFAULT = "DEFAULT"; public SecureCreditCard() { //initialize credit_card to default value credit_card = DEFAULT; } //allows callers to modify (private) internal state public void changeCC(String newCC) { if (credit_card.equals(newCC)) { // no change return; } else { // check permissions to modify credit_card performSecurityManagerCheck(); validateInput(newCC); credit_card = newCC; } } // readObject correctly enforces checks during deserialization private void readObject(ObjectInputStream in) { in.defaultReadObject(); // if the deserialized name does not match the default value normally // created at construction time, duplicate the checks if (!DEFAULT.equals(credit_card)) { performSecurityManagerCheck(); validateInput(credit_card); } } // allows callers to retrieve internal state public String getValue() { // check permission to get value performSecurityManagerCheck(); return somePublicValue; } // writeObject correctly enforces checks during serialization private void writeObject(ObjectOutputStream out) { // duplicate check from getValue() performSecurityManagerCheck(); out.writeObject(credit_card); } } |
...
Allowing serialization or deserialization to bypass the Security Manager may result in sensitive data being compromised exposed or modified.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
SER32- J | high | probable | high | P6 | L2 |
...