Naive use of object serialization may allow a malicious party with access to the serialization byte stream to read private data, create objects with illegal or dangerous state, or obtain references to the private fields of deserialized objects. Implementors concerned with security should be aware of the following implications of serialization:
-
Default serialization of an object writes the values of all fields of that object to the serialization stream, regardless of whether or not they are public. Malicious code can effectively read the values of private fields of a serializable object by serializing the object and then examining the resulting byte stream. Methods for avoiding this problem are described in Section A.4, "Preventing Serialization of Sensitive Data".
-
During deserialization, objects are created and initialized using data from the incoming serialization stream. If the stream was corrupted or tampered with prior to deserialization, the deserialized objects may have unexpected or illegal state. Methods for avoiding this problem are described in Section A.5, "Writing Class-Specific Serializing Methods".
-
By inserting extra wire handle references into a serialization byte stream, it is possible during deserialization to forge extra references to objects occurring earlier in the stream. Therefore, it is unsafe for developers to assume that references to private objects obtained via deserialization are unique. Techniques for dealing with this problem are discussed in section Section A.6, "Guarding Unshared Deserialized Objects".
-
Objects implementing the Externalizable interface are susceptible to overwriting, since the readExternal method is public. A caller can invoke the readExternal method at any time, passing it an arbitrary stream to read values from, causing the target object to be reinitialized. A means of preventing this is outlined in Section A.7, "Preventing Overwriting of Externalizable Objects".
CONTENTS | PREV
| NEXT