SER01-J. Limit the accessibility of readObject and writeObject methods

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 the writeObject() method 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 the accessibility of the class constructor (if any); otherwise it should be reduced to private.

Even when hostile code does not have access to the serializable class's members, serialization may fail to work as expected. The ObjectInputStream.readObject() and ObjectOutputStream.writeObject() methods are declared final and cannot be overridden. The custom form of serialization involves a mechanism that allows the JVM to detect and use private implementations of the two methods in the serializable class. If the accessibility of the two methods is not private, the default serialization form takes effect. This can be insecure from many standpoints, for instance, input validation checks installed in the custom serialized form may be bypassed.

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()).

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

Similarly, omission of the static keyword does not make this example secure because the two methods will not be detected by the JVM, resulting in failure to use the custom serialized form.

Compliant Solution

This compliant solution declares the readObject() and writeObject() methods private and non-static 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();
}

Reducing the accessibility also prevents malicious overriding of the two methods.

Risk Assessment

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

Automated Detection

TODO

Related Vulnerabilities

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

Bibliography

[[Sun 2006]] "Serialization specification"
[[Ware 2008]]

SER00-J. Maintain serialization compatibility during class evolution      16. Serialization (SER)      SER02-J. Extendable classes should not declare readResolve() and writeReplace() private or static