Serialization

The readObject method on ObjectInputStream acts as a "magic constructor" that can instantiate objects of almost any type on the class path that implements Serializable. During deserialization:

• It can execute code from any of these types
• The entire codebase of all serializable classes constitutes the attack surface
• Attackers can craft malicious byte streams targeting vulnerable methods (gadgets)
• Multiple gadgets can be chained together to form a "gadget chain"

Example attack: The 2016 San Francisco Metropolitan Transit Agency ransomware attack exploited serialization vulnerabilities to execute arbitrary code.

A deserialization bomb is a small serialized byte stream deliberately crafted to consume excessive resources when deserialized, causing denial-of-service.

Example implementation:

// Creates a structure that takes exponential time to deserialize
static byte[] createBomb() {
    Set<Object> root = new HashSet<>();
    Set<Object> s1 = root;
    Set<Object> s2 = new HashSet<>();
    
    for (int i = 0; i < 100; i++) {
        Set<Object> t1 = new HashSet<>();
        Set<Object> t2 = new HashSet<>();
        t1.add("foo");  // Make t1 unequal to t2
        s1.add(t1); s1.add(t2);
        s2.add(t1); s2.add(t2);
        s1 = t1;
        s2 = t2;
    }
    
    return serialize(root);
}

This creates 201 HashSet instances in a structure requiring over 2^100 hashCode calculations during deserialization, with bounded stack depth and few objects, making it undetectable until resources are exhausted.

The default serialized form is appropriate only when a class's physical representation aligns with its logical content. Evaluate using these criteria:

• Does the serialized form contain only the logical data represented by the object?
• Is it independent of the physical implementation details?
• Will it remain valid across reasonable implementation changes?
• Is the encoding reasonably efficient?

Appropriate example:

// Good candidate for default serialization
public class Name implements Serializable {
    private final String firstName;  // Logical component
    private final String lastName;   // Logical component
    // Constructor, methods, etc.
}

Inappropriate example: A hash table where the logical content is key-value mappings but the physical representation includes buckets, load factors, and hash functions.

Cross-platform structured-data representations that serve as safer alternatives:

JSON:

• Text-based, human-readable format
• Originally developed for JavaScript
• Simple attribute-value pairs structure
• No built-in schema enforcement

Protocol Buffers (protobuf):

• Binary format (more efficient)
• Developed by Google
• Schema-based with strong typing
• Includes text representation (pbtxt) for debugging

Fundamental differences from Java serialization:

• No support for arbitrary object graphs or automatic serialization
• Support only simple structured data objects with attribute-value pairs
• Limited to primitive types and arrays rather than arbitrary objects
• No automatic deserialization of untrusted types
• Focus on cross-platform compatibility rather than Java-specific functionality

These alternatives provide better security, performance, tooling, and cross-language support at the cost of not supporting arbitrary object graphs.

Design Principle: Before making a field nontransient, confirm that its value is truly part of the logical state of the object, not just an implementation detail.

Fields that should generally be marked transient:

1. Derived data that can be computed from other fields:

   private final List<Item> items;             // Not transient (core data)
   private transient int totalPrice;           // Transient (derived)
   private transient Map<String, Item> lookup; // Transient (derived)

2. Caches or performance optimization structures:

   private transient volatile Map<K,V> cache;

3. JVM-specific resources that can't be meaningfully serialized:

   private transient FileHandle nativeFileHandle;
   private transient Thread processingThread;
   private transient Socket connection;

4. Implementation details that might change between versions:

   // Internal linked list representation of a collection
   private transient Entry head, tail;
   private transient int size;

5. Security-sensitive information that shouldn't be persisted:

   private String username;                  // Not transient
   private transient char[] passwordBuffer;  // Transient for security

6. Thread-local or context-specific state:

   private transient ThreadLocal<Context> threadContext;

The goal is to serialize only the

Accessibility considerations for readResolve in class hierarchies:

1. For final classes:

   • Use private accessibility for readResolve

2. For non-final classes:

   • private: Will NOT apply to any subclasses
   • package-private: Will apply ONLY to subclasses in the same package
   • protected/public: Will apply to ALL subclasses that don't override it

Security issue with protected/public readResolve:

• If a subclass doesn't override the readResolve method
• Deserializing a subclass instance will produce a superclass instance
• This likely causes ClassCastException when the code expects the subclass type

Example vulnerability:

// Superclass with protected readResolve
public class Super implements Serializable {
    public static Super INSTANCE = new Super();
    
    protected Object readResolve() {
        return INSTANCE; // Returns Super.INSTANCE
    }
}

// Subclass without readResolve override
public class Sub extends Super implements Serializable {
    // No readResolve override
}

// Usage causing ClassCastException
Sub sub = (Sub) deserialize(serializedSubInstance);
// ClassCastException: Super cannot be cast to Sub

Attack against immutable classes:

1. The attack pattern:

   • Serialize a valid immutable object
   • Manually append "rogue references" to the object's private mutable fields
   • Deserialize to obtain both the immutable object and direct references to its internal fields
   • Modify the internal fields, bypassing encapsulation

2. How it circumvents invariant checking:

   • The initial object passes all invariant checks during deserialization
   • But the attacker gains direct access to the object's internals
   • Changes can be made that would normally be blocked by encapsulation
   • This can create objects in states that would be impossible to create through normal API use

3. Why it works:

   • Java serialization exposes object internals
   • Immutability relies on encapsulation, which serialization can bypass
   • Valid invariant checks only verify the object's state at deserialization time
   • Java serialization protocol allows appending additional objects to the stream

This is why defensive copying in readObject is critical - it breaks the connection between deserialized objects and the internal fields of the immutable class.

EnumSet uses the serialization proxy pattern to dynamically choose between RegularEnumSet and JumboEnumSet implementations:

// Inside EnumSet
private static class SerializationProxy<E extends Enum<E>> 
        implements Serializable {
    // The element type of this enum set
    private final Class<E> elementType;
    
    // The elements contained in this enum set
    private final Enum<?>[] elements;
    
    SerializationProxy(EnumSet<E> set) {
        elementType = set.elementType;
        elements = set.toArray(new Enum<?>[0]);
    }
    
    private Object readResolve() {
        // Create the appropriate implementation based on current conditions
        EnumSet<E> result = EnumSet.noneOf(elementType);
        for (Enum<?> e : elements)
            result.add((E)e);
        return result;
    }
    
    private static final long serialVersionUID = 362491234563181265L;
}

This implementation enables:

1. Serializing a RegularEnumSet (for enums ≤64 elements)
2. Adding elements to the enum type between serialization and deserialization
3. Deserializing into a JumboEnumSet when appropriate (for enums >64 elements)

The key is that readResolve() uses the factory method EnumSet.noneOf() which chooses the right implementation class based on the current size of the enum type.

The serialization proxy pattern excels at maintaining class invariants:

1. Complete preservation of invariants

   • Uses public constructors/APIs that already enforce invariants
   • No special-case code for deserialization that might bypass validation
   • Avoids the "secret constructor" problem of traditional serialization

2. Elimination of duplicate validation logic

   • Traditional approach: Duplicate validation in constructors and readObject()
   • Proxy approach: Single validation in constructors, reused during deserialization

3. Better handling of representation invariants

   • The readResolve() method can choose the optimal implementation
   • Can adapt to runtime conditions (like EnumSet choosing implementation)
   • Can enforce complex interdependencies between fields

4. Safer evolution path

   • Adding new invariants only requires updating constructors
   • No need to update separate deserialization code
   • Reduces risk when refactoring class implementations

This approach treats serialization as a true constructor mechanism rather than a special backdoor into object creation.

Purpose and Importance

• serialVersionUID is a unique identifier for serializable classes that ensures version compatibility
• It verifies class compatibility during deserialization to prevent InvalidClassException
• Acts as a "version number" for the serialized format of a class

Without Explicit Declaration:

• JVM automatically generates it at runtime using SHA-1 cryptographic hash
• Auto-generation considers:
  • Class name and interfaces
  • All members (including compiler-generated synthetic members)
  • Even minor changes (adding a private method, changing a comment) can alter the generated UID
  • Impossible to predict which changes will affect the generated value

Implementation Best Practice:

private static final long serialVersionUID = 123456789L; // any long value

Benefits of Explicit Declaration:

1. Eliminates compatibility risk from minor class modifications
2. Improves performance by avoiding expensive runtime computation
3. Provides controlled version management of serialized formats

When to Change the Value:

• Change only when intentionally breaking compatibility with existing serialized instances
• Keep the same when newer versions should accept serialized objects from older versions
• For existing classes without a serialVersionUID, use the serialver utility to find the auto-generated value

Note: Even with matching serialVersionUIDs, serialization will fail if field types or names change incompatibly. The explicit declaration prevents automatic incompatibility, but doesn't guarantee complete compatibility.