Page History

Every serializable class that has private mutable instance variables must defensively copy them in the readObject() method. An adversary attacker can tamper with the serialized form of such a class, appending extra references to the byte stream. When deserialized, this byte stream could allow the creation of a class instance whose internal variable references are controlled by the attacker. Consequently, this allows the class instance of the container class to can mutate and violate its class invariants.

This rule is an instance of OBJ14OBJ06-J. Defensively copy mutable inputs and mutable internal components. Whereas that rule , which applies to constructors , and to other methods that take accept untrusted mutable parameters, this arguments. This rule applies the same principle to deserialized mutable fields.

Noncompliant Code Example

This noncompliant code example lacks defensive copying of the date object, which is mutablefails to defensively copy the mutable Date object date. An attacker may might be able to create an instance of MutableSer whose date object contains a nefarious subclass of Date and whose methods can do the attacker's biddingperform actions specified by an attacker. Any code that depends on the immutability of the sub-object subobject is vulnerable.

class MutableSer implements Serializable {
  private static final Date epoch = new Date(0);
  private Date date = null; // Mutable component
  
  public MutableSer(Date d){
    date = new Date(d.getTime()); // Constructor performs defensive copying
  }

  private void readObject(ObjectInputStream ois) throws IOException, ClassNotFoundException {
    ois.defaultReadObject();
    // Perform validation if necessary
  }
}

Compliant Solution

This compliant solution creates a defensive copy of the mutable Date object date object in the readObject() method. Note the use of field-by-field input and validation of incoming fields (see guideline SER04-J. Validate deserialized objects for additional information). Additionally, note that this compliant solution is insufficient to protect sensitive data (see guideline SER03-J. Do not serialize unencrypted sensitive data for additional information).

private void readObject(ObjectInputStream ois) throws IOException, ClassNotFoundException {
  ObjectInputStream.GetField fields = ois.readFields();
  Date inDate = (Date) fields.getFieldget("date", epoch);
  // Defensively copy the mutable component
  date = new Date(inDate.getTime());
  // Perform validation if necessary
}

...

There is no need to copy immutable sub-objects subobjects. Also, avoid using the sub-objectsubobject's {{clone()}} method because it can be overridden when the sub-objectsubobject's class is non-final. Moreover, it produces only a shallow copy. The sub-objects ({{date}}) themselves must be non-final so that defensive copying can occur. It is also inadvisable to use the {{writeUnshared()}} and {{readUnshared()}} methods as an alternative \[[Bloch 2008|AA. Bibliography#Bloch 08]\]not final and produces only a shallow copy. The references to the subobjects themselves must be nonfinal so that defensive copying can occur. It is also inadvisable to use the writeUnshared() and readUnshared() methods as an alternative [Bloch 2008].

Risk Assessment

Failure to defensively copy mutable components during deserialization can violate the immutability contract of an object.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

Bibliography

\[[API 2006|AA. Bibliography#API 06]\]
\[[Bloch 2008|AA. Bibliography#Bloch 08]\] Item 76: "Write readObject methods defensively"
\[[Sun 2006|AA. Bibliography#Sun 06]\] "Serialization specification: A.6  Guarding Unshared Deserialized Objects"

Automated Detection

Related Guidelines

Bibliography

...

Image Added Image Added Image AddedSER06-J. Do not serialize instances of inner classes      16. Serialization (SER)      SER08-J. Do not use the default serialized form for implementation-defined invariants