Serialization and deserialization features can be exploited to bypass security manager checks. A serializable class may contain security manager checks in its constructors for various reasons, including preventing untrusted code from modifying the internal state of the class. Such security manager checks must be replicated at all points where a class instance can be constructed. So if a 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 extract sensitive information by deserializing the object.
Noncompliant Code Example
In this noncompliant code example, security manager checks are used within the constructor but are omitted from the writeObject()
and readObject()
methods that are used in the serialization-deserialization process. This omission allows untrusted code to maliciously create instances of the class.
public final class Hometown implements Serializable { // Private internal state private String town; private static final String UNKNOWN = "UNKNOWN"; void performSecurityManagerCheck() throws AccessDeniedException { // ... } void validateInput(String newCC) throws InvalidInputException { // ... } public Hometown() { performSecurityManagerCheck(); // Initialize town to default value town = UNKNOWN; } // Allows callers to retrieve internal state String getValue() { performSecurityManagerCheck(); return town; } // Allows callers to modify (private) internal state public void changeTown(String newTown) { if (town.equals(newTown)) { // No change return; } else { performSecurityManagerCheck(); validateInput(newTown); town = newTown; } } // writeObject() correctly enforces checks during serialization private void writeObject(ObjectOutputStream out) throws IOException { out.writeObject(town); } // readObject() correctly enforces checks during deserialization private void readObject(ObjectInputStream in) throws IOException { in.defaultReadObject(); // If the deserialized name does not match the default value normally // created at construction time, duplicate the checks if (!UNKNOWN.equals(town)) { validateInput(town); } } }
Despite the security manager checks, the data is not considered sensitive because a sensitive serializable class would violate SER03-J. Do not serialize unencrypted, sensitive data.
AccessDeniedException
and InvalidInputException
are both unchecked security exceptions that can be thrown by any method without requiring a throws
declaration.
Compliant Solution
This compliant solution implements the required security manager checks in all constructors and methods that can either modify or retrieve internal state. Consequently, an attacker cannot create a modified instance of the object (using deserialization) or read the serialized byte stream to reveal serialized data.
public final class Hometown implements Serializable { // ... all methods the same except the following: // writeObject() correctly enforces checks during serialization private void writeObject(ObjectOutputStream out) throws IOException { performSecurityManagerCheck(); out.writeObject(town); } // readObject() correctly enforces checks during deserialization private void readObject(ObjectInputStream in) throws IOException { in.defaultReadObject(); // If the deserialized name does not match the default value normally // created at construction time, duplicate the checks if (!UNKNOWN.equals(town)) { performSecurityManagerCheck(); validateInput(town); } } }
Refer to rule SEC04-J. Protect sensitive operations with security manager checks to learn about implementing the performSecurityManagerCheck()
method which is important to protect against the finalizer attack.
Risk Assessment
Allowing serialization or deserialization to bypass the security manager may result in classes being constructed without required security checks.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
SER04-J |
high |
probable |
high |
P6 |
L2 |
Related Guidelines
Secure Coding Guidelines for the Java Programming Language, Version 3.0 |
Guideline 5-4 Duplicate the |
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="2be9a76a-fd08-44d1-a86e-68dd13661573"><ac:plain-text-body><![CDATA[ |
[[Long 2005 |
AA. Bibliography#Long 05]] |
Section 2.4, Serialization |
]]></ac:plain-text-body></ac:structured-macro> |
SER03-J. Do not serialize unencrypted, sensitive data 13. Serialization (SER)