Page History

While serialization allows an object's state to be saved as a sequence of bytes and then reconstituted at a later time, it provides no mechanism to protect the serialized data. An attacker who gains access to the serialized data can use it to discover sensitive information and to determine implementation details of the objects. An attacker can also modify the serialized data in an attempt to compromise the system when the malicious data is deserialized. Consequently, sensitive data that is serialized is potentially exposed, without regard to the access qualifiers (such as the private keyword) that were used in the original code. Moreover, the security manager lacks checks to cannot guarantee the integrity of the serialized deserialized data.

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

This rule is meant to prevent the unintentional serialization of sensitive information. Rule SER02-J. Sign then seal sensitive objects before sending them outside a trust boundary applies to the intentional serialization of sensitive information.

...

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 {
      if (fout != null) {
        try {
          fout.close();
        } catch (IOException x) {
          // handle error
        }
      }
    }
 }
}

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.

When serializing a class that contains sensitive data, programs must ensure that sensitive data is omitted from the serialized form. This includes suppressing both suppressing serialization of data members that contain sensitive data , and also suppressing serialization of references to non-serializable or sensitive objects.

This compliant solution both avoids the possibility of incorrect serialization and also protects sensitive data members from accidental serialization by declaring the relevant members as transient so that they are omitted from the list of fields to be serialized by the default serialization mechanism.

public class Point {
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
    } finally {
      if (fout != null) {
        try {
          fout.close();
        } catch (IOException x) {
          // handle error
        }
      }
    }
  }
}

Compliant Solution

Other compliant solutions include:

*developing 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 *defining the serialPersistentFields array field and ensure ensuring that sensitive fields are omitted from the array. (See rule SER00-J. Maintain serialization compatibility during class evolution.)

...

Serialization can also be used maliciously., Onefor example, isto returningreturn multiple instances of a singleton-like class object. In this noncompliant code example (based on \[[Bloch 2005|AA. Bibliography#Bloch 05]\]), a subclass {{SensitiveClass}} inadvertently becomes serializable because it extends the {{Exceptionjava.lang.Number}} class, which implements {{Serializable}}.

public class SensitiveClass extends ExceptionNumber {
  // ..implement  publicabstract methods, such as Number.doubleValue()…

  private static final SensitiveClass INSTANCE = new SensitiveClass();
  public static SensitiveClass getInstance() {
    return INSTANCE;
  }

  private SensitiveClass() {
    // Perform security checks and parameter validation
  }

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

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

  // 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);
    }
  }
}

See rule MSC07-J. Prevent multiple instantiations of singleton objects 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 inappropriate 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 ExceptionNumber {
  // ...

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

...

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

...

Related Guidelines

...

...