Page History

If a class implements Externalizable, Classes that implement the Externalizable interface must provide the readExternal() and writeExternal() methods must be provided. Unfortunately, these methods are public and, consequently, . These methods have package-private or public access, and so they can be called by hostile code which can potentially trusted and untrusted code alike. Consequently, programs must ensure that these methods execute only when intended and that they cannot overwrite the internal state of the object at any point objects at arbitrary points during program execution.

Noncompliant Code Example

This noncompliant code example allows anyone any caller to reset the value of the object due to the public access modifier of at any time because the readExternal method.() method is necessarily declared to be public and lacks protection against hostile callers:

public void readExternal(ObjectInput in) 
                         throws IOException, ClassNotFoundException {
   // readRead 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 after which the instance fields are populated. Finally, the flag is set to true so that the fields cannot be overwrittencompliant solution protects against multiple initialization through the use of a Boolean flag that is set after the instance fields have been populated. It also protects against race conditions by synchronizing on a private lock object (see LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code).

private final Object lock = new Object();
private boolean initialized = false;

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

Note that this compliant solution is inadequate to protect sensitive data.

Risk Assessment

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

Automated Detection

...

Tool	Version	Checker	Description
Parasoft Jtest	Include Page Parasoft_V Parasoft_V	CERT.SER11.IRX	Avoid re-initializing fields in the 'readExternal()' method of 'Externalizable' classes

Bibliography

...

Image Added Image Added Image Added

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      12. Serialization (SER)      SER36-J. Do not use the default serialized form for implementation defined invariants