SER36-J. Do not use the default serialized form for implementation defined invariants

According to [[API 06]] class Object, method hashcode() documentation:

Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.

Consequently, the hashcode of an object need not remain consistent across different executions of the application. Similarly, if an object is serialized, its hashcode may not stay consistent with the original value. This introduces several hurdles; for example, upon deserialization it is impossible to retrieve the object because its corresponding key could have changed.

Noncompliant Code Example

The Key class is being used as the key index for the hashtable in this noncompliant code example. According to [[API 06]] class Hashtable documentation:

To successfully store and retrieve objects from a hashtable, the objects used as keys must implement the hashCode method and the equals method.

This example follows the above advice but serialization is still at the mercy of the implementation of the hashcode method. It is not required to produce a key value (hashcode) that is consistent across different executions of the program or during (de)serialization. Consequently, using the default serialized form of the hashtable may be inappropriate. In this example, it is not possible to retrieve the value of the object using the original key after deserialization.

class Key implements Serializable {
  //overrides hashcode and equals methods
}

class HashSer {
  public static void main(String[] args) throws IOException, ClassNotFoundException {
    Hashtable<Key,String> ht = new Hashtable<Key, String>();
    Key key = new Key();
    ht.put(key, "Value");
    System.out.println("Entry: " + ht.get(key)); // retrieve using the key, works
	 
    // Serialize the Hashtable object
    FileOutputStream fos = new FileOutputStream("hashdata.ser");
    ObjectOutputStream oos = new ObjectOutputStream(fos);
    oos.writeObject(ht);
    oos.close();
	 
    // Deserialize the Hashtable object
    FileInputStream fis = new FileInputStream("hashdata.ser");
    ObjectInputStream ois = new ObjectInputStream(fis);
    Hashtable<Key, String> ht_in = (Hashtable)(ois.readObject());
    ois.close();
	 
    if(ht_in.contains("Value")) // check if the object actually exists in the Hashtable
      System.out.println("Value was found in deserialized object.");
	 
    if (ht_in.get(key) == null) // gets printed
      System.out.println("Object was not found when retrieved using the key.");	 
  }
}

Compliant Solution

One solution is to change the type of the key value so that it remains consistent across different runs of the program and the multitude of JVMs. This can be achieved by using an Integer object, for example, to hold the key values.

class HashSer {
  public static void main(String[] args) throws IOException, ClassNotFoundException {
    Hashtable<Integer,String> ht = new Hashtable<Integer, String>();
    ht.put(new Integer(1), "Value");
    System.out.println("Entry: " + ht.get(1)); // retrieve using the key
	 
    // Serialize the Hashtable object
    FileOutputStream fos = new FileOutputStream("hashdata.ser");
    ObjectOutputStream oos = new ObjectOutputStream(fos);
    oos.writeObject(ht);
    oos.close();
	 
    // Deserialize the Hashtable object
    FileInputStream fis = new FileInputStream("hashdata.ser");
    ObjectInputStream ois = new ObjectInputStream(fis);
    Hashtable<Integer, String> ht_in = (Hashtable)(ois.readObject());
    ois.close();
	 
    if(ht_in.contains("Value")) // check if the object actually exists in the Hashtable
      System.out.println("Value was found in deserialized object.");
	 
    if (ht_in.get(1) == null)  // does not get printed
      System.out.println("Object was not found when retrieved using the key.");	 
  }
}

This problem can also be avoided by overriding the equals and the hashcode method in the Key class, though it is best to avoid employing hash tables that are known to use implementation defined parameters.

Risk Assessment

Serializing objects with implementation defined characteristics can seriously corrupt the state of the object.

Automated Detection

TODO

Related Vulnerabilities

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

References

[[API 06]] Class Object, Class Hashtable
[[Bloch 08]] Item 75: "Consider using a custom serialized form"

SER35-J. Prevent overwriting of Externalizable Objects      12. Serialization (SER)      SER37-J. Do not deserialize from a privileged context