You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 29 Next »

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.

Guideline

Severity

Likelihood

Remediation Cost

Priority

Level

SER13-J

low

probable

low

P6

L2

Automated Detection

TODO

Related Vulnerabilities

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

Bibliography

[[API 2006]]
[[Sun 2006]] "Serialization specification: A.7 Preventing Overwriting of Externalizable Objects"


SER12-J. Avoid memory and resource leaks during serialization      16. Serialization (SER)      49. Miscellaneous (MSC)

  • No labels