ABSTRACT

A serializable class that performs a SecurityManager check in its constructor needs to perform the same check in its readObject() and readObjectNoData methods.

EXPLANATION

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();
}
}


REFERENCES

[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