Securing Serialization and Deserialization

Now the discussion about serialization and deserialization is about why it should be avoided in many instances and handled with care in others.
Note: Deserialization of untrusted data is inherently dangerous and should be avoided. The serialization provides an interface two classes that sidestep the field access control mechanisms of the Java language. Making a class serializable effectively creates a public interface to all fields of that class. Serialization also affectively adds a hidden public instructor to a class, which needs to be considered when trying to restrict object construction. Once an object has been serialized the Java languages access controls can no longer be enforced and attackers can access private fields in an object by analyzing its serialized byte stream. Deserialization creates a new instance of a class without invoking any constructor on that class. Deserialization of untrusted data is dangerous and should be avoided whenever possible. If it must occur, it should be handled with great care as described in some of these guidelines.

Avoid serialization for security sensitive classes. Points: Making a class serializable can expose all the fields of a class to a bad actor, and should be avoided.

Guard sensitive data during serialization. Points: Approaches for handling sensitive fields in serializable classes are:

1. Declare sensitive fields transient
2. Define the serialPersistentFields array field appropriately.
3. Implement writeObject and use ObjectOutputStream.putField selectively
4. Implement writeReplace to replace the instance with a serial proxy.
5. implement the Externalizable interface.

Externalizable

View Deserialization the same as object construction.
Notes: Deserialization should be designed to behave like normal construction.

1. Perform the same input validation checks in a readObject method implementation as the constructor
2. Create copies of deserialized mutable objects before assigning them to internal fields in a readObject implementation
3. Ensure a serializable class remains totally unusable until deserialization completes successfully. For example, use an initialized flag.

Duplicate the SecurityManager checks enforced in a class during serialization and deserialization.
Important Points

1. If a serializable class enforces a SecurityManager check in its constructors, then enforce that same check in a readObject or readObjectNoData6method implementation.
2. An attacker can serialize an object to bypass a security check and access the internal state simply by reading the serialized byte stream.