...
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 allows untrusted code to maliciously create instances of the class. Despite the security manager checks, the data is not considered sensitive, as a sensitive serializable class would violate SER03-J. Prevent serialization of unencrypted, sensitive data.
We assume that AccessDeniedException and InvalidInputException are both security exceptions, and, for that reason, are not checked. So any method can throw them without requiring a throws declaration.
| Code Block | ||
|---|---|---|
| ||
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, as a sensitive serializable class would violate SER03-J. Prevent serialization of unencrypted, sensitive data.
We assume that AccessDeniedException and InvalidInputException are both security exceptions, and, for that reason, are not checked. So any method can throw them 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.
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="58bdac50ebe1cd75-8cb45aa8-44744310-be888d89-cdd03df9a4f922122cf2c8ff"><ac:plain-text-body><![CDATA[ | [[Long 2005 | AA. Bibliography#Long 05]] | Section 2.4, Serialization | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="be244e8de362dc97-af2059ab-49fc4b81-897a9bb6-823e7e731d3f866e5c5496f7"><ac:plain-text-body><![CDATA[ | [[SCG 2007 | AA. Bibliography#SCG 07]] | Guideline 5-3 Duplicate the SecurityManager checks enforced in a class during serialization and deserialization | ]]></ac:plain-text-body></ac:structured-macro> |
...