SER35-J. Prevent overwriting of Externalizable Objects

If a class implements Externalizable, the readExternal() and writeExternal() methods must be provided. Unfortunately, these methods are public and, consequently, can be called by hostile code capable of overwriting the internal state of the object at any point during program execution.

Noncompliant Code Example

This noncompliant code example allows anyone to reset the value of the object because of 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 compliant solution is thread-safe and allows the caller to check the initialized flag after 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]]
[[Sun 06]] "Serialization specification: A.7 Preventing Overwriting of Externalizable Objects"

SER34-J. Make defensive copies of private mutable components      14. Serialization (SER)      SER36-J. Do not use the default serialized form for implementation defined invariants