FIO32-J. Do not serialize sensitive data

Object serialization allows saving an object's state as a sequence of bytes and its reconstitution at a later time. The primary application of serialization is in Java Remote Method Invocation (RMI) wherein objects must be (un)packed and exchanged between distributed virtual machines. It also finds extensive use in Java Beans.

Java language's access control mechanisms cease to remain effective after a class is serialized. Consequently, any sensitive data that was originally protected using access qualifiers (such as the private keyword) gets exposed. Moreover, the security manager does not provide any checks to guarantee integrity of serialized data.

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. The coordinates (x,y) that are written to the data stream are susceptible 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)
 {
  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) {System.err.println(e);} 
 }
}

Compliant Solutions

In the absence of sensitive data, a class can be serialized by 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 sub classes will also inherit this interface and will as a result be serializable.

When serialization is unavoidable, it is still possible to have classes that cannot implement serializable. This condition is common when there are references to non-serializable objects within the contained methods. The following compliant solution avoids this issue and also protects sensitive data members from getting serialized accidentally. The basic idea is to declare the target member as transient so that it is not included in the list of fields to be serialized, whenever default serialization is being used.

public class Point {

 private transient double x;
 private transient 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 (Exception e) {System.err.println(e);} 
 }
}

Other ruses include custom implementation of writeObject, writeReplace and writeExternal methods such that sensitive fields are not written to the serialized stream or alternatively, conducting proper validation checks while de-serializing. Yet another remediation is to define the serialPersistentFields array field and ensuring that sensitive fields are not added to the array. Sometimes it is necessary to prevent a serializable object (whose superclass implements serializable) from getting serialized. This can be achieved by throwing a NotSerializableException from the custom writeObject() method.

Risk Assessment

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

Automated Detection

TODO

Related Vulnerabilities

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

References

AP
[[JLS 05]] Transient modifier
[[Harold 99]]
[[SCG 07]]