...
| 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 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 (Throwable t) {
// Forward to handler
}
}
}
|
...
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 subclasses also inherit this interface and are consequently serializable. This simple approach is inappropriate for any class that contains sensitive data.
...
| 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) {
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
}
}
}
|
Compliant Solution
Other Another acceptable solutions include solution involves using custom implementations of the writeObject(), writeReplace() and writeExternal() methods that prevent sensitive fields from being written to the serialized stream.
Compliant Solution
, 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 omitted from the array. (See guideline SER00-J. Maintain serialization compatibility during class evolution.)
...
| Code Block | ||
|---|---|---|
| ||
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
Extending a class or interface that implements Serializable should be avoided whenever possible. When extension 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. Note that the custom writeObject() or readResolve() methods must be declared final to prevent a malicious subclass from overriding them.
| Code Block | ||
|---|---|---|
| ||
class SensitiveClass extends Exception {
// ...
private final Object readResolve() throws NotSerializableException {
throw new NotSerializableException();
}
}
|
...