If a class implements Externalizable, the readExternal and writeExternal methods have to be provided. Unfortunately, these methods are public and thus can be called by hostile code which can potentially overwrite the internal state of the object at any point during program execution.

Noncompliant Code Example

This noncompliant example allows anyone to reset the value of the object due to the public access modifier of the readExternal method.

public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException {
   // read instance fields
   this.name = (String)in.readObject();
   this.UID = in.readInt();
   //...
}

Compliant Solution

This thread-safe solution allows the first caller to check the initialized flag following which, the instance fields are populated. Finally, the flag is set to true so that the fields cannot be overwritten.

public synchronized void readExternal(ObjectInput in)
 throws IOException, ClassNotFoundException {
  if (!initialized) {
    // read instance fields
    this.name = (String)in.readObject();
    this.UID = in.readInt();
    //...  
    initialized = true;
  } else {
    throw new IllegalStateException();
  }
}

Risk Assessment

Failure to prevent the overwriting of externalizable objects can corrupt the state of the object.

Automated Detection

TODO

Related Vulnerabilities

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

References

\[[API 06|AA. Java References#API 06]\]
\[[Sun 06|AA. Java References#Sun 06]\] "Serialization specification: A.7  Preventing Overwriting of Externalizable Objects"

SER34-J. Make defensive copies of private mutable components      11. Serialization (SER)      11. Serialization (SER)