Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This rule is an instance of OBJ06-J. Defensively copy mutable inputs and mutable internal components. Whereas that rule applies to constructors, and other methods that take untrusted mutable parameters, 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 mutable. An attacker may be able to create an instance of MutableSer whose date object contains a nefarious subclass of Date whose methods can do the attacker's bidding. Any code that depends on the immutability of the sub-object is vulnerable.

Code Block
bgColor#FFcccc
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 in the readObject() method. Note the use of field-by-field input and validation of incoming fields (see rule void SER04-J. Validate deserialized objects for additional information). Additionally, note that this compliant solution is insufficient to protect sensitive data (see rule SER03-J. Prevent serialization of unencrypted, sensitive data for additional information).

...

Wiki Markup
There is no need to copy immutable sub-objects. Also, avoid using the sub-object's {{clone()}} method because it can be overridden when the sub-object'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]\].

Risk Assessment

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

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SER07-J

low

probable

medium

P4

L3

Related Vulnerabilities

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

Bibliography

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="d1cca9e8b69e3c7e-d116d4b1-49ef4596-87ffb700-18dab550eeefeb03c34982fa"><ac:plain-text-body><![CDATA[

[[API 2006

AA. Bibliography#API 06]]

 

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="e648dba5cf824429-0911158d-4ae64d91-bb66b6ad-8f7bcca2e7f7d799dd955e8d"><ac:plain-text-body><![CDATA[

[[Bloch 2008

AA. Bibliography#Bloch 08]]

Item 76: "Write readObject methods defensively"

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="3cc1cca9433f7d03-74bc1e6f-421046ef-8ec9965c-982415377f9df9290d1b4ff3"><ac:plain-text-body><![CDATA[

[[Sun 2006

AA. Bibliography#Sun 06]]

"Serialization specification: A.6 Guarding Unshared Deserialized Objects"

]]></ac:plain-text-body></ac:structured-macro>

...