Page History

Object Although serialization allows an object's state to be saved as a sequence of bytes and then reconstituted at a later time. Default serialization lacks protection for data that has been serialized, it provides no mechanism to protect the serialized data. An attacker who gains access to the serialized data can use it to discover sensitive data, information and to determine implementation details of the objects, and for many other purposes. Similarly, an . 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 that could 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. SER02-J. Sign then seal 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 declared as private. The saveState() and readState() methods are used for serialization and de-serialization respectively. If Assuming the coordinates were sensitive (as we assume for this example)are sensitive, their presence in the data stream exposes would expose them to malicious tampering.

public class Point implements Serializable {
  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);
      FileOutputStream fout = new FileOutputStream("point.ser");
      ObjectOutputStream oout = new ObjectOutputStream(fout);
      oout.writeObject(p);
    } catch (Throwable t) { 
      // Forward to handler 
    } finally {
      if (fout != null) {
        try {
          ooutfout.close();
        } catch (ThrowableIOException tx) {
    
      // Forward to handler  Handle error
        }
      }
    }
  }

...

}

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 sub classes subclasses also inherit this interface and are consequently serializable. This simple approach is inappropriate for any class that contains sensitive data.

Compliant Solution

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 nonserializable 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 implements Serializable {
 private transient double x; // declaredDeclared transient
 private transient double y; // declaredDeclared transient

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

 public Point()
 {
   //no 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);
      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
        }
      }
    }
  }
}

Other acceptable compliant solutions include using

• Developing custom implementations of the writeObject(), writeReplace(), and writeExternal() methods that prevent sensitive fields from being written to the serialized stream

...

• .
• Defining the serialPersistentFields array field and

...

• ensuring that sensitive fields are omitted from the array

...

• (

...

• see SER00-J.

...

• Enable 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}}.maliciously, for example, to return multiple instances of a singleton class object. In this noncompliant code example (based on [Bloch 2005]), a subclass SensitiveClass inadvertently becomes serializable because it extends the java.lang.Number class, which implements Serializable:

Code Block
bgColor #FFcccc
public class SensitiveClass extends ExceptionNumber { // ... Implement abstract methods, such as Number.doubleValue()… publicprivate static final SensitiveClass INSTANCE = new SensitiveClass(); public static SensitiveClass getInstance() { return INSTANCE; } private SensitiveClass() { // Perform security checks and parameter validation } protectedprivate int balance printBalance() {= 1000; protected int balance = 1000;getBalance() { 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.INSTANCEgetInstance()); // Prints false; indicates new instance 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 MSC07-J. Prevent multiple instantiations of singleton objects for more information about singleton classes.

Compliant Solution

Extending a class or interface that implements Serializable should be avoided whenever possible. For instance, a nonserializable class could contain an instance of a serializable class and delegate method calls to the serializable class.

When extension of such a serializable class by an unserializable class is necessary, undue inappropriate serialization of the subclass can be prohibited by throwing a NotSerializableException from a custom writeObject(), readObject() or readResolve, and readObjectNoData() method methods, defined in the nonserializable subclass SensitiveClass. Note that the custom writeObject() or readResolve() These custom methods must be declared final to prevent a malicious subclass from overriding themprivate (see SER01-J. Do not deviate from the proper signatures of serialization methods for more information).

class SensitiveClass extends ExceptionNumber {
  // ...

  private final Object writeObject(java.io.ObjectOutputStream out) throws NotSerializableException {
    throw new NotSerializableException();
  }
  private final Object readResolve(readObject(java.io.ObjectInputStream in) throws NotSerializableException {
    throw new NotSerializableException();
  }
  private final Object readObjectNoData(java.io.ObjectInputStream in) throws NotSerializableException {
    throw new NotSerializableException();
  }
}

It is still possible for an attacker to obtain uninitialized instances of SensitiveClass by catching NotSerializableException or by using a finalizer attack (see OBJ11-J. Be wary of letting constructors throw exceptions for more information). Consequently, an unserializable class that extends a serializable class must always validate its invariants before executing any methods. That is, any object of such a class must inspect its fields, its actual type (to prevent it being a malicious subclass), and any invariants it possesses (such as being a malicious second object of a singleton class).

Exceptions

SER03-J-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 linkconnection, or stored in an insecure mediumlocation, or disclosed inappropriately.

Automated Detection

Related Vulnerabilities

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

Bibliography

\[[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"

Related Guidelines

Bibliography

...

Image Added Image Added Image AddedSER02-J. Extendable classes should not declare readResolve() and writeReplace() private or static      16. Serialization (SER)      SER04-J. Validate deserialized objects