...
The data members of class Point are private. Assuming the coordinates are sensitive, their presence in the data stream would expose them to malicious tampering.
| Code Block | ||
|---|---|---|
| ||
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) {
FileOutputStream fout = null;
try {
Point p = new Point(5, 2);
fout = new FileOutputStream("point.ser");
ObjectOutputStream oout = new ObjectOutputStream(fout);
oout.writeObject(p);
} catch (Throwable t) {
// Forward to handler
} finally {
if (fout != null) {
try {
fout.close();
} catch (IOException x) {
// handle error
}
}
}
}
}
|
...
This compliant solution both avoids the possibility of incorrect serialization and 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.
| Code Block | ||
|---|---|---|
| ||
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) {
FileOutputStream fout = null;
try {
Point p = new Point(5,2);
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 compliant solutions include:*developing
- Developing custom implementations of the
writeObject(),writeReplace(), andwriteExternal()methods that prevent sensitive fields from being written to the serialized stream.
...
- Defining the
serialPersistentFieldsarray field and ensuring that sensitive fields are omitted from the array. (See rule SER00-J. Enable serialization compatibility during class evolution.)
Noncompliant Code Example
Serialization can be used 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 | ||
|---|---|---|
| ||
public class SensitiveClass extends Number {
// ..implement abstract methods, such as Number.doubleValue()â¦
private static final SensitiveClass INSTANCE = new SensitiveClass();
public static SensitiveClass getInstance() {
return INSTANCE;
}
private SensitiveClass() {
// Perform security checks and parameter validation
}
protected int getBalance() {
int balance = 1000;
return balance;
}
}
class Malicious {
public static void main(String[] args) {
SensitiveClass sc =
(SensitiveClass) deepCopy(SensitiveClass.getInstance());
// Prints false; indicates new instance
System.out.println(sc == SensitiveClass.getInstance());
System.out.println("Balance = " + sc.getBalance());
}
// This method should not be used in production 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 rule 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 a serializable class by an unserializable class is necessary, inappropriate serialization of the subclass can be prohibited by throwing NotSerializableException from custom writeObject(), readObject(), and readObjectNoData() methods, defined in the nonserializable subclass. These custom methods must be declared private or final to prevent a malicious subclass from overriding them.
| Code Block | ||
|---|---|---|
| ||
class SensitiveClass extends Number {
// ...
protected final Object writeObject(java.io.ObjectOutputStream out) throws NotSerializableException {
throw new NotSerializableException();
}
protected final Object readObject(java.io.ObjectInputStream in) throws NotSerializableException {
throw new NotSerializableException();
}
protected final Object readObjectNoData(java.io.ObjectInputStream in) throws NotSerializableException {
throw new NotSerializableException();
}
}
|
...
Puzzle 83. Dyslexic monotheism | |
Item 1. Enforce the singleton property with a private constructor | |
| |
[JLS 2005] | |
Section 2.4, Serialization | |
[Sun 2006] | Serialization Specification, A.4, Preventing Serialization of Sensitive Data |
SER02-J. Sign then seal sensitive objects before sending them outside a trust boundary 13. Serialization (SER)