SER13-J. Treat data to be deserialized as potentially malicious by default

A Serializable class can overload the Serializable.readObject() method, which is called when an object of that class is being deserialized.  This method (as well the method readResolve()) must treat the serialized data as potentially malicious and refrain from performing potentially dangerous operations, unless the programmer has expressly indicated, for the particular deserialization at hand, that the class may perform potentially dangerous operations. 

This rule complements rule SER12-J. Prevent deserialization of untrusted classes.  Whereas SER12-J requires the programmer to validate data before deserializing it (to ensure the absence of classes that might perform dangerous operations when deserialized), 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, since there is a lot of existing code that violates these rules, the CERT Coding Standard takes the "belt and suspenders" approach of requiring compliant code to follow both rules.

Non-Compliant Code Example

The class OpenedFile in the following non-compliant code example opens a file during deserialization.  Operating systems typically impose a limit on the number of open file handles per process, and this limit is typically is not very large (e.g., 1024).  Consequently, deserializing a list of OpenedFile objects can exhaust the process's available file handles and cause the program to malfunction.

import java.io.*;

class OpenedFile implements Serializable {
  public String filename;
  public BufferedReader reader;

  public OpenedFile(String _filename) {
    filename = _filename;
    init();
  }
  private void init() {
    try {
      reader = new BufferedReader(new FileReader(filename));
    } catch (FileNotFoundException e) { }
  }
    
  private void writeObject(ObjectOutputStream out) throws IOException {
    out.writeUTF(filename);
  }

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

Compliant Solution

In the below compliant solution, the readObject() method throws an exception unless the potentially dangerous class is whitelisted.

import java.io.*;

interface Whitelist {
  public boolean has(String className);
}

class WhitelistedObjectInputStream extends ObjectInputStream {
  Whitelist whitelist;

  public WhitelistedObjectInputStream(InputStream inputStream) throws IOException {
    super(inputStream);
  }

  public void setWhitelist(Whitelist wl) {
    whitelist = wl;
  }
}
 
class OpenedFile implements Serializable {
  public String filename;
  public BufferedReader reader;
  public OpenedFile(String _filename) {
    filename = _filename;
    init();
  }
  private void init() {
    try {
      reader = new BufferedReader(new FileReader(filename));
    } catch (FileNotFoundException e) { }
  }
    
  private void writeObject(ObjectOutputStream out) throws IOException {
    out.writeUTF(filename);
  }
  private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
    boolean isWhitelisted = ((in instanceof WhitelistedObjectInputStream) &&
      ((WhitelistedObjectInputStream) in).whitelist.has(this.getClass().getName()));
    if (!isWhitelisted) {
      throw new SecurityException("Attempted to deserialize unexpected class.");
    }
    filename = in.readUTF();
    init();
  }
}

Risk Assessment

Automated Detection

Related Guidelines

Bibliography