Page History

...

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

When serialization is unavoidable, it is possible that the class suffers from serializability issues. Usually, this happens when there are serializing a class that contains sensitive data, programs must ensure that sensitive data is omitted from the serialized form. This includes both suppressing serialization of data members that contain sensitive data, and also suppressing serialization of references to non-serializable or sensitive objects within the serializable class.
This compliant solution both avoids the possibility of incorrect serialization and also protects sensitive data members from being serialized accidentally. The basic idea is to declare the target member accidental serialization by declaring the relevant members as transient so that it is not included in they are omitted from the list of fields to be serialized , whenever by the default serialization is usedmechanism.

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

Other acceptable solutions include using custom implementation implementations of the writeObject(), writeReplace() and writeExternal() methods so that prevent sensitive fields are not from being written to the serialized stream or alternatively, conducting proper validation checks while deserializing. Yet another remedy , or use of custom implementations of the readObject(), readExternal() and readResolve() methods that conduct proper validation checks during deserialization; these techniques are often combined. Another acceptable approach is to define the serialPersistentFields array field and ensure that sensitive fields are not added to omitted from the array. (See guideline SER00-J. Maintain serialization compatibility during class evolution.) Sometimes it is necessary to prevent a serializable object (whose superclass implements Serializable) from being serialized. This is the focus of the second noncompliant code example.

Noncompliant Code Example

Serialization can also be used maliciously, to return. 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 asbecause it extends the {{Exception}} class thatwhich implements {{Serializable}}. (This is based on \[[Bloch 2005|AA. Bibliography#Bloch 05]\].)

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

Ideally, extending Extending a class or interface that implements Serializable should be avoided whenever possible. When this is not possibleextension 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. It is also required to declare the methods Note that the custom writeObject() or readResolve() methods must be declared final to prevent a malicious subclass from overriding them.

...

Automated Detection

...

Related Vulnerabilities

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

Bibliography

\[[JLSBloch 2005|AA. Bibliography#JLSBibliography#Bloch 05]\] [Transient modifier|http://java.sun.com/docs/books/jls/third_edition/html/classes.html#37020]
\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 5-1 Guard sensitive data during serializationPuzzle 83: Dyslexic Monotheism
\[[SunBloch 20062001|AA. Bibliography#SunBibliography#Bloch 0601]\] "SerializationItem specification1: A.4Enforce the Preventingsingleton Serializationproperty ofwith Sensitive Data"
\[[Harold 1999|AA. Bibliography#Harold 99]\]
\[[Long 2005|AA. Bibliography#Long 05]\] Section 2.4, Serializationa private constructor
\[[Greanier 2000|AA. Bibliography#Greanier 00]\] [Discover the secrets of the Java Serialization API|http://java.sun.com/developer/technicalArticles/Programming/serialization/]
\[[BlochHarold 20051999|AA. Bibliography#BlochBibliography#Harold 0599]\] Puzzle 83: Dyslexic Monotheism
\[[BlochJLS 20012005|AA. Bibliography#BlochBibliography#JLS 0105]\] Item 1: Enforce the singleton property with a private constructor[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"

...

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