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.

1. Permanent API binding - It permanently ties the exported API to the current internal representation (private implementation details become part of the public API)

2. Excessive space consumption - The serialized form may include implementation details not worthy of inclusion, making it unnecessarily large

3. Excessive time consumption - The serialization logic must perform an expensive graph traversal with no knowledge of the object graph topology

4. Stack overflow risk - The recursive traversal of the object graph can cause stack overflows even for moderately sized object graphs (as few as 1,000-1,800 elements in some cases)

You must still invoke defaultWriteObject() and defaultReadObject() even if all fields are transient.

The serialization specification requires these calls to enable:

• Forward compatibility (new fields can be added in future versions)
• Backward compatibility (older versions can deserialize newer instances)

Without these calls, if an instance is serialized in a later version and deserialized in an earlier version, the deserialization would fail with a StreamCorruptedException.

Default values for transient fields after deserialization:

• Object references: null
• Numeric primitives: 0 (zero)
• Boolean: false

Handling strategies for transient fields:

1. Explicit initialization in readObject:

private void readObject(ObjectInputStream s) 
        throws IOException, ClassNotFoundException {
    s.defaultReadObject();
    // Initialize transient fields to proper values
    transientCounter = 0;
    transientCache = new HashMap<>();
    // Recreate derived data from deserialized fields
    transientTotal = calculateTotal();
}

2. Lazy initialization (initialize when first accessed):

// Field declaration
private transient volatile Map<K,V> transientCache;

// Accessor with lazy initialization
public Map<K,V> getCache() {
    Map<K,V> result = transientCache;
    if (result == null) {
        synchronized(this) {
            result = transientCache;
            if (result == null) {
                transientCache = result = new HashMap<>();
                // Populate from non-transient state
            }
        }
    }
    return result;
}

Choose between these approaches based on:

• Whether initialization is expensive (favor lazy initialization)
• Whether the field is always needed immediately after deserialization
• Thread-safety requirements

// Proper readObject with defensive copying and validation
private void readObject(ObjectInputStream s) throws IOException, ClassNotFoundException {
    s.defaultReadObject();
    
    // 1. Defensively copy mutable components
    start = new Date(start.getTime());
    end = new Date(end.getTime());
    
    // 2. Validate the object's invariants
    if (start.compareTo(end) > 0)
        throw new InvalidObjectException(start + " after " + end);
}

Critical points:

• Defensive copying MUST occur BEFORE validation
• Use direct new object creation rather than .clone() for better security
• Fields must be made non-final to allow modification during deserialization
• This protects against both invalid state and mutation attacks

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.

public final class Complex implements Serializable {
    private final double re;
    private final double im;
    
    public Complex(double re, double im) {
        this.re = re;
        this.im = im;
    }
    
    public double realPart() { return re; }
    public double imaginaryPart() { return im; }
    
    public Complex add(Complex c) {
        return new Complex(re + c.re, im + c.im);
    }
    
    // Additional methods omitted
    
    // Serialization proxy pattern implementation
    private static class SerializationProxy implements Serializable {
        private final double re;
        private final double im;
        
        SerializationProxy(Complex c) {
            this.re = c.re;
            this.im = c.im;
        }
        
        private static final long serialVersionUID = 923745298374L;
        
        private Object readResolve() {
            // Uses the public constructor to create a new instance
            return new Complex(re, im);
        }
    }
    
    // Prevents direct serialization of Complex
    private Object writeReplace() {
        return new SerializationProxy(this);
    }
    
    // Prevents direct deserialization of Complex
    private void readObject(ObjectInputStream stream) 
            throws InvalidObjectException {
        throw new InvalidObjectException("Proxy required");
    }
}

public class ThreadSafeCache<K, V> implements Serializable {
    private final ConcurrentHashMap<K, V> map = new ConcurrentHashMap<>();
    private final transient ReadWriteLock lock = new ReentrantReadWriteLock();
    
    // Constructor and other methods omitted
    
    public V get(K key) {
        lock.readLock().lock();
        try {
            // Defensive copy to prevent modification of returned objects
            V value = map.get(key);
            return value != null ? defensiveCopy(value) : null;
        } finally {
            lock.readLock().unlock();
        }
    }
    
    public void put(K key, V value) {
        lock.writeLock().lock();
        try {
            // Defensive copy to prevent modification of stored objects
            map.put(key, defensiveCopy(value));
        } finally {
            lock.writeLock().unlock();
        }
    }
    
    @SuppressWarnings("unchecked")
    private V defensiveCopy(V value) {
        // Implementation depends on type V
        return (V) deepCopy(value);
    }
    
    private Object deepCopy(Object obj) {
        // Deep copy implementation omitted
        return obj; // Placeholder
    }
    
    // Serialization Proxy Pattern implementation
    private static class SerializationProxy<K, V> implements Serializable {
        private final Map<K, V> mapSnapshot;
        
        SerializationProxy(ThreadSafeCache<K, V> cache) {
            // Take a snapshot of the map during serialization
            this.mapSnapshot = new HashMap<>(cache.map);
        }
        
        private static final long serialVersionUID = 24562456245624562L;
        
        private Object readResolve() {
            ThreadSafeCache<K, V> cache = new ThreadSafeCache<>();
            // Restore the map state
            cache.map.putAll(mapSnapshot);
            return cache;
        }
    }
    
    private Object writeReplace() {
        return new SerializationProxy<>(this);
    }
    
    private void readObject(ObjectInputStream stream) 
            throws InvalidObjectException {
        throw new InvalidObjectException("Proxy required");
    }
}

This implementation:

1. Combines defensive copying for regular operations with the serialization proxy pattern
2. Creates a snapshot during serialization to preserve thread-safety
3. Recreates the cache during deserialization using proper construction
4. Maintains all invariants throughout the serialization process

The readObject() method that throws an exception is essential for security reasons:

private void readObject(ObjectInputStream stream) 
    throws InvalidObjectException {
    throw new InvalidObjectException("Proxy required");
}

This method serves as a critical security barrier:

1. Prevents direct deserialization attacks

   • Without this method, an attacker could create a malicious byte stream representing the enclosing class
   • This would bypass the serialization proxy mechanism entirely
   • The attacker could potentially create invalid objects that violate class invariants

2. Enforces the proxy-only deserialization path

   • Ensures all deserialization goes through the readResolve() method of the proxy
   • Creates a "fail-fast" behavior for any attempts to circumvent the proxy

3. Completes the security model

   • writeReplace() ensures proper serialization
   • readObject() ensures proper deserialization
   • Together they form a complete protection mechanism

If this method were omitted, the serialization proxy pattern would only work for non-malicious use cases, leaving a significant security vulnerability.

When designing a serializable superclass, implement these key considerations to ensure proper subclass serialization and security:

Constructor and Initialization Requirements

• Provide an accessible parameterless constructor:

  protected SuperClass() {
      // Initialize fields to maintain invariants
  }

• Handle the readObjectNoData scenario to protect against adding a serializable superclass:

  private void readObjectNoData() throws InvalidObjectException {
      // Initialize fields or throw exception if unsafe
  }

Inheritance Design Patterns

1. Protected initialization methods for subclass serialization support:

   protected void initializeFrom(DataInput in) throws IOException {
       // Read and initialize state
   }
   
   protected void writeTo(DataOutput out) throws IOException {
       // Write state
   }

2. Consider providing protected readResolve() and writeReplace() methods
3. Document serialized form implications for subclasses

Security Protections

• Make finalize final to prevent finalizer attacks:

  @Override
  final protected void finalize() throws Throwable {
      // Cleanup code
      super.finalize();
  }

• Consider making critical methods final to prevent override during deserialization
• Use readResolve to validate deserialized objects

Serialized Form Optimization

• Minimize serialized state - only include essential fields
• Mark implementation details as transient
• Avoid constructor dependencies - deserialization bypasses constructors of non-serializable superclasses

Note: Without these precautions, subclass serialization may fail or introduce security vulnerabilities.