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 capable of overwriting 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 because of the public access modifier of at any time because the readExternal() method .is necessarily declared to be public and lacks protection against hostile callers:

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 protects against multiple initialization through the use of a Boolean flag that is set after the instance fields are populated. Finally, the flag is set to true so that the fields cannot be overwrittenhave 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();
public synchronizedprivate boolean initialized = false;

public void readExternal(ObjectInput in)
                         throws IOException, ClassNotFoundException {
  synchronized (lock) {
    if (!initialized) {
      // Read 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

...

TODO

Related Vulnerabilities

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

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