Page History

If a class implements Externalizable, public 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 through multiple callsat any point during program execution.

Noncompliant Code Example

...

This thread-safe solution allows the first caller to set an 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)