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.

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.

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.

When implementing a custom readObject method for a thread-safe class, you must ensure that:

1. The readObject method includes the same synchronization as any other method that reads the entire state of the object

2. The synchronization in readObject adheres to the same lock-ordering constraints as other activities in the codebase

Failure to follow the same lock-ordering constraints can lead to resource-ordering deadlocks when deserialization occurs concurrently with other operations.

Example of correct implementation:

// Proper synchronized readObject method
private synchronized void readObject(ObjectInputStream s)
    throws IOException, ClassNotFoundException {
    s.defaultReadObject();
    // Any additional validation or state restoration
}

The @serialData tag is used to document the serialized form data written and read by custom writeObject, readObject, writeExternal, and readExternal methods, while @serial is used to document fields that are part of the serialized form.

Purpose:

• Documents the sequence, types, and meanings of data written during serialization
• Helps maintain consistency between serialization and deserialization
• Creates public documentation of the custom serialized form structure
• Appears on the special serialized forms page in generated Javadoc

Example usage:

/**
 * Serialize this collection.
 *
 * @serialData The size of the collection (int) is emitted, followed by
 *             each of its elements in insertion order. Each element is
 *             written as an Object.
 */
private void writeObject(ObjectOutputStream s) throws IOException {
    s.defaultWriteObject();
    
    // Write size
    s.writeInt(size);
    
    // Write elements in order
    for (E e : this) {
        s.writeObject(e);
    }
}

The tag should clearly describe:

1. The sequence of data
2. The exact types of data written
3. The meaning of each data item
4. Any conditions or special cases in the format

The most secure approach is to use an enum singleton:

// Enum singleton - the preferred approach
public enum Elvis {
    INSTANCE;
    
    private String[] favoriteSongs = { "Hound Dog", "Heartbreak Hotel" };
    
    public void printFavorites() {
        System.out.println(Arrays.toString(favoriteSongs));
    }
}

Advantages:

• Java guarantees only one instance exists
• Immune to serialization attacks (built into Java's enum serialization)
• No need for readResolve method
• Immune to reflection attacks

If enum is not possible:

1. Implement readResolve method
2. Make ALL object reference fields transient
3. Consider accessibility of readResolve (private for final classes)

Vulnerable code:

public class Elvis implements Serializable {
    public static final Elvis INSTANCE = new Elvis();
    private Elvis() { }
    private String[] favoriteSongs = { "Hound Dog", "Heartbreak Hotel" };
    
    private Object readResolve() {
        return INSTANCE;
    }
}

Fundamental problem:

• Contains a non-transient object reference field (favoriteSongs)
• During deserialization, this field is populated BEFORE readResolve runs

Exploitation:

1. Create a "stealer" class that captures the reference to the deserialized instance
2. The readResolve method will return the canonical INSTANCE, but the attacker now has a reference to a second instance
3. This breaks the singleton guarantee

Proper fix:

• Make all fields transient: private transient String[] favoriteSongs
• Or better: use an enum singleton instead

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.

Defensive Copying Approach:

// Field declarations
private Date start;
private Date end;

// Must be non-final for serialization to work
private void readObject(ObjectInputStream s) 
        throws IOException, ClassNotFoundException {
    s.defaultReadObject();
    
    // Defensively copy to avoid attack
    start = new Date(start.getTime());
    end = new Date(end.getTime());
    
    // Validate invariants
    if (start.compareTo(end) > 0) {
        throw new InvalidObjectException("Start after end");
    }
}

Serialization Proxy Pattern:

// Fields can be final
private final Date start;
private final Date end;

// Serialization proxy
private static class SerializationProxy implements Serializable {
    private final Date start;
    private final Date end;
    
    SerializationProxy(Period p) {
        this.start = p.start;
        this.end = p.end;
    }
    
    private Object readResolve() {
        return new Period(start, end); // Uses public constructor
    }
}

private Object writeReplace() {
    return new SerializationProxy(this);
}

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

Key differences:

1. Field mutability: Proxy allows final fields, defensive copying doesn't
2. Validation: Proxy reuses constructor validation, defensive copying duplicates it
3. Security: Proxy prevents attacks by design, defensive copying mitigates them
4. Complexity: Proxy is more structured but requires more boilerplate
5. Performance: Defensive copying is ~14% faster
6. Flexibility: Proxy allows changing implementation class during deserialization