Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Examples of sensitive data that should remain unserialized include cryptographic keys, digital certificates, and classes that may hold references to sensitive data at the time of serialization.

This rule addresses unintentional serialization of sensitive data. For information on intentionally serializing sensitive data securely, see SER02-J. Sign and seal sensitive objects before transit.

Noncompliant Code Example

The data members of class Point are declared as private. If the coordinates were sensitive (as we assume for this example), their presence in the data stream would expose them to malicious tampering.

Code Block
bgColor#FFcccc
public class Point {
  private double x;
  private double y;

  public Point(double x, double y) {
    this.x = x;
    this.y = y;
  }

  public Point() {
    // no-argument constructor
  }
}

public class Coordinates extends Point implements Serializable {
  public static void main(String[] args) {
    try {
      Point p = new Point(5, 2);
      FileOutputStream fout = new FileOutputStream("point.ser");
      ObjectOutputStream oout = new ObjectOutputStream(fout);
      oout.writeObject(p);
      oout.close();
    } catch (Throwable t) { 
      // Forward to handler 
    }
 }
}

Compliant Solution

In the absence of sensitive data, classes can be serialized by simply implementing the java.io.Serializable interface. By doing so, the class indicates that no security issues may result from the object's serialization. Note that any derived subclasses also inherit this interface and are consequently serializable. This simple approach is inappropriate for any class that contains sensitive data.

...

Code Block
bgColor#ccccff
public class Point {
 private transient double x; // declared transient
 private transient double y; // declared transient

 public Point(double x, double y) {
  this.x = x;
  this.y = y;
 }

 public Point() {
   // no-argument constructor
 }
}

public class Coordinates extends Point implements Serializable {
  public static void main(String[] args) {
    try {
      Point p = new Point(5,2);
      FileOutputStream fout = new FileOutputStream("point.ser");
      ObjectOutputStream oout = new ObjectOutputStream(fout);
      oout.writeObject(p);
      oout.close();
    } catch (Exception e) {
      // Forward to handler
    }
  }
}

Compliant Solution

Another acceptable solution involves using custom implementations of the writeObject(), writeReplace() and writeExternal() methods that prevent sensitive fields from being written to the serialized stream.

Compliant Solution

Another acceptable approach is to define the serialPersistentFields array field and ensure that sensitive fields are omitted from the array. (See rule SER00-J. Maintain serialization compatibility during class evolution.)

Noncompliant Code Example

Wiki Markup
Serialization can also be used maliciously. One example is returning multiple instances of a singleton-like class. In this noncompliant code example (based on \[[Bloch 2005|AA. Bibliography#Bloch 05]\]), a subclass {{SensitiveClass}} inadvertently becomes serializable because it extends the {{Exception}} class which implements {{Serializable}}.

Code Block
bgColor#FFcccc
public class SensitiveClass extends Exception {
  public static final SensitiveClass INSTANCE = new SensitiveClass();
  private SensitiveClass() {
    // Perform security checks and parameter validation
  }

  protected int printBalance() {
    int balance = 1000;
    return balance;
  }
}

class Malicious {
  public static void main(String[] args) {
    SensitiveClass sc = (SensitiveClass) deepCopy(SensitiveClass.INSTANCE);
    System.out.println(sc == SensitiveClass.INSTANCE);  // Prints false; indicates new instance
    System.out.println("Balance = " + sc.printBalance());
  }

  // This method should not be used in production quality code
  static public Object deepCopy(Object obj) {
    try {
      ByteArrayOutputStream bos = new ByteArrayOutputStream();
      new ObjectOutputStream(bos).writeObject(obj);
      ByteArrayInputStream bin = new ByteArrayInputStream(bos.toByteArray());
      return new ObjectInputStream(bin).readObject();
    } catch (Exception e) { 
      throw new IllegalArgumentException(e);
    }
  }
}

Compliant Solution

Extending a class or interface that implements Serializable should be avoided whenever possible. When extension of such a class is necessary, undue serialization of the subclass can be prohibited by throwing a NotSerializableException from a custom writeObject() or readResolve() method, defined in the subclass SensitiveClass. Note that the custom writeObject() or readResolve() methods must be declared final to prevent a malicious subclass from overriding them.

Code Block
bgColor#ccccff
class SensitiveClass extends Exception {
  // ...

  private final Object readResolve() throws NotSerializableException {
    throw new NotSerializableException();
  }
}

Exceptions

SER03:EX0: Sensitive data that has been properly encrypted may be serialized. See SER02-J. Sign and seal sensitive objects before transit for how to do this properly.

Risk Assessment

If sensitive data can be serialized, it may be transmitted over an insecure link, or stored in an insecure medium, or disclosed inappropriately.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SER03-J

medium

likely

high

P6

L2

Related Vulnerabilities

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

Bibliography

Wiki Markup
\[[Bloch 2005|AA. Bibliography#Bloch 05]\] Puzzle 83: Dyslexic Monotheism
\[[Bloch 2001|AA. Bibliography#Bloch 01]\] Item 1: Enforce the singleton property with a private constructor
\[[Greanier 2000|AA. Bibliography#Greanier 00]\] [Discover the secrets of the Java Serialization API|http://java.sun.com/developer/technicalArticles/Programming/serialization/]
\[[Harold 1999|AA. Bibliography#Harold 99]\]
\[[JLS 2005|AA. Bibliography#JLS 05]\] [Transient modifier|http://java.sun.com/docs/books/jls/third_edition/html/classes.html#37020]
\[[Long 2005|AA. Bibliography#Long 05]\] Section 2.4, Serialization
\[[MITRE 2009|AA. Bibliography#MITRE 09]\] [CWE ID 502|http://cwe.mitre.org/data/definitions/502.html] "Deserialization of Untrusted Data", [CWE ID 499|http://cwe.mitre.org/data/definitions/499.html] "Serializable Class Containing Sensitive Data"
\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 5-1 Guard sensitive data during serialization
\[[Sun 2006|AA. Bibliography#Sun 06]\] "Serialization specification: A.4  Preventing Serialization of Sensitive Data"

...