Page History

...

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 meant to prevent the unintentional serialization of sensitive data. For information on intentionally serializing sensitive data securely, see information. Rule SER02-J. Sign and seal sensitive objects before sending them outside a trust boundary applies to the intentional serialization of sensitive information.

Noncompliant Code Example

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

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) {
    FileOutputStream fout = null;
    try {
      Point p = new Point(5, 2);
      fout = new FileOutputStream("point.ser");
      ObjectOutputStream oout = new ObjectOutputStream(fout);
      oout.writeObject(p);
    } catch (Throwable t) { 
      // Forward to handler 
    } finally {
      fout.close();
    }
 }
}

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.

...

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

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}}.

...

See rule MSC11-J. Address the shortcomings of the Singleton design pattern for more information on singletons.

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.

class SensitiveClass extends Exception {
  // ...

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

Exceptions

SER03:EX0: Sensitive data that has been properly encrypted may be serialized.

Risk Assessment

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

Related Vulnerabilities

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

Related Guidelines

Bibliography

...