Page History

...

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() {
    // noNo 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 (Throwable t) { /* forwardForward to handler */ }
 }
}

Compliant Solution

...

When serialization is unavoidable, it is still possible to have classes that cannot implement serializable effectively. 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
 }

}

import java.io.Serializable;
import java.io.FileOutputStream;
import java.io.ObjectOutputStream;

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

      // Forward to handler
    }
  }
}

Other solutions include using custom implementation of writeObject(), writeReplace() and writeExternal() methods such so that sensitive fields are not written to the serialized stream or alternatively, conducting proper validation checks while deserializing. Yet another remedy is to define the serialPersistentFields array field and ensure ensuring that sensitive fields are not added to the array (SER00-J. Maintain serialization compatibility during class evolution). Sometimes it is necessary to prevent a serializable object (whose superclass implements serializable) from getting serialized. This is the focus of the second noncompliant code example.

...

Serialization can also be used maliciously to return multiple instances of a singleton-like class. In this noncompliant code example, a subclass {{SensitiveClass}} inadvertently becomes Serializableserializable as it extends the {{Exception}} class that implements {{Serializable}}. (Based on \[[Bloch 05|AA. Java References#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);  // printsPrints 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

Undue serialization of the subclass can be prohibited by throwing a NotSerializableException from a custom writeObject() method or the readResolve() method, defined in the subclass SensitiveClass. Ideally, extending a class or interface that implements Serializable should be avoided. It is also required to declare the methods final to prevent a malicious subclass from overriding them.

...