A serializable class that performs a SecurityManager
check in its constructor needs to perform the same check in its readObject()
and readObjectNoData
methods.
When a serializable class's readObject()
method is invoked, the constructor for the class being deserialized is not invoked. Thus, if a SecurityManager
check is present in the constructor of a serializable class, the same SecurityManager
check must also be present in the readObject()
and readObjectNoData()
methods. Otherwise, the security check will be bypassed when the class is deserialized.
Example 1: The following code contains a SecurityManager
check in the constructor but not in the readObject()
and readObjectNoData()
methods.
public class BadSecurityCheck implements Serializable {
private int id;
public BadSecurityCheck() {
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(new BadPermission("BadSecurityCheck"));
}
id = 1;
}
public void readObject(ObjectInputStream in) throws ClassNotFoundException, IOException {
in.defaultReadObject();
}
public void readObjectNoData(ObjectInputStream in) throws ClassNotFoundException, IOException {
in.defaultReadObject();
}
}
[1] "Secure Coding Guidelines for the Java Programming Language, version 2.0" Sun Microsystems, Inc. [Online]. [Accessed: Aug. 30, 2007]. Sun Microsystems, Inc.
[2] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 358
[3] C. Lai Java Insecurity: Accounting for Subtleties That Can Compromise Code