Page History

A Serializable class can overload the Serializable.readObject() method, which is called when an object of that class is being deserialized.  Both this method and the method readResolve() should refrain from performing potentially dangerous operations.

This rule guideline complements rule SER12-J. Prevent deserialization of untrusted data.  Whereas SER12-J requires the programmer to ensure the absence of classes that might perform dangerous operations by validating data before deserializing it, SER13-J data to be deserialized is trusted, this guideline requires that all serializable classes refrain, by default, from performing dangerous operations during deserialization.   SER12-J and SER13-J both guard against the same class of deserialization vulnerabilities.  Theoretically, a given system is secure against this class of vulnerabilities if either (1) all deployed code on that system follows SER12-J or (2) all deployed code on that system follows SER13-J.  However, because much existing code violates both of these rules, the CERT Coding Standard takes the "belt and suspenders" approach and requires compliant code to follow both rulesThis guideline is intended to address legacy code that must deserialize untrusted input, despite violating SER12-J.

For compliance with SER13-Jthis guideline, it is permitted to assume that, if an ObjectInputStream contains a whitelist, then control will pass to the readObject() or readResolve() method of a class C only if C is class if and only if that class is on the whitelist.  In other words, a class does not need to check that it appears on the whitelist; it only needs to check that a whitelist exists.  This eliminates the need to perform a redundant check against the whitelist, and it enables compatibility with a greater range of whitelist implementations.

...