Page History

A Serializable class can overload the Serializable.readObject() method, which is called when an object of that class is being deserialized.  Both this method and the method readResolve() must treat the serialized data as potentially malicious and must refrain from performing potentially dangerous operations, unless the programmer has expressly whitelisted the class for the particular deserialization at hand.  When deserialization is performed without a whitelist, it is a violation of this rule to perform any potentially dangerous operations.

This rule complements rule SER12-J. Prevent deserialization of untrusted classes.  Whereas SER12-J requires the programmer to ensure the absence of classes that might perform dangerous operations by validating data before deserializing it, SER13-J requires that all serializable classes refrain, by default, from performing dangerous operations during deserialization.  SER12-J and SER13-J both guard against the same class of deserialization vulnerabilities.  Theoretically, a given system is secure against this class of vulnerabilities if either (1) all deployed code on that system follows SER12-J or (2) all deployed code on that system follows SER13-J.  However, because much existing code violates both of these rules, the CERT Coding Standard takes the "belt and suspenders" approach and requires compliant code to follow both rules.

...

import java.io.*;
 
class OpenedFile implements Serializable {
  public String filename;
  public BufferedReader reader;

  public OpenedFile(String _filename) throws FileNotFoundException {
    filename = _filename;
  }

  public void init() throws FileNotFoundException {
    reader = new BufferedReader(new FileReader(filename));
  }
     
  private void writeObject(ObjectOutputStream out) throws IOException {
    out.writeUTF(filename);
  }

  private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
    filename = in.readUTF();
  }
}

Risk Assessment

The severity of violations of this rule depend on the nature of the potentially dangerous operations performed.  If only mildly dangerous operations are performed, the risk might be limited to denial-of-service (DoS) attacks.  At the other extreme, remote code execution is possible is attacker-supplied input is supplied to methods such as Runtime.exec (either directly or via reflection).

...