Page History

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 anywhere a class instance can be constructed. So For example, 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.

...

Despite the security manager checks, the data in this example is not considered sensitive because a sensitive serializable class would violate sensitive. Serializing unencrypted, sensitive data violates rule SER03-J. Do not serialize unencrypted, sensitive data.

...

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.

The ObjectInputStream.defaultReadObject() fills the object's fields with data from the input stream. Because each field is deserialized recursively, it is possible for the this reference to escape from control of the deserialization routines. This can happen if a referenced object publishes the this reference in its constructors or field initializers. See rule TSM01-J. for more information. To be compliant, no subobjects being recursively deserialized may publish the this object reference.

Risk Assessment

Allowing serialization or deserialization to bypass the security manager may result in classes being constructed without required security checks.

...

...

...