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

Compare with Current View Page History

« Previous Version 9 Next »

The serialization and deserialization mechanism must respect the accessibility of the implementing class. Untrusted code should not be able to write to the stream using writeObject() nor should it be able to create an instance of the object by calling the readObject() method. The accessibility of these methods must match with that of the class constructor (if any); otherwise it should be reduced to private.

Noncompliant Code Example

This noncompliant code example shows a class Ser, which has a private constructor. This means that code external to the class should be unable to create its instance. The class implements java.io.Serializable and defines the readObject() and writeObject() methods. The accessibility of both the methods is public which allows untrusted code to obtain the reconstituted object (in case of readObject()) and write to the stream (in case of writeObject()).

class Ser implements Serializable {
  private static final long serialVersionUID = 123456789;
  private Ser() {
    // initialize
  }
  public void writeObject(final ObjectOutputStream stream) throws IOException {
    stream.defaultWriteObject();
  }
	
  public void readObject(final ObjectInputStream stream) throws 
      IOException, ClassNotFoundException {
    stream.defaultReadObject();
  }
}

Compliant Solution

This compliant solution declares the readObject() and writeObject() methods private to limit their accessibility.

private void writeObject(final ObjectOutputStream stream) throws IOException {
  stream.defaultWriteObject();
}
	
private void readObject(final ObjectInputStream stream) throws 
    IOException, ClassNotFoundException {
  stream.defaultReadObject();
}

Risk Assessment

Failure to limit the accessibility of the readObject() and writeObject() methods can leave code vulnerable to untrusted invocations.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SER02- J

high

likely

low

P27

L1

Automated Detection

TODO

Related Vulnerabilities

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

References

[[Sun 06]] "Serialization specification"
[[Ware 08]]


SER12-J. Avoid memory and resource leaks during serialization      14. Serialization (SER)      SER02-J. Extendable classes should not declare readResolve() and writeReplace() private or static

  • No labels