Object serialization allows an object's state to be saved as a sequence of bytes and then reconstituted at a later time. The primary application of serialization is in Java Remote Method Invocation (RMI) wherein objects must be packed (marshalled), exchanged between distributed virtual machines and subsequently unpacked (unmarshalled). It also finds extensive use in Java Beans.
Java language's access control mechanisms are ineffective after a class is serialized. Consequently, any sensitive data that was originally protected using access qualifiers (such as the private keyword) are exposed. Moreover, the security manager does not provide any checks to guarantee integrity of the serialized data.
Examples of sensitive data that should not be serialized are cryptographic keys, digital certificates, and classes that may hold references to sensitive data at the time of serialization.
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.
| 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) {
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
}
}
}
|
Compliant Solution
In the absence of sensitive data, a class can be serialized by implementing the java.io.Serializable interface (sensitive classes should not implement this interface). By doing so, the class indicates that no security issues may result from the object's serialization. Note that any derived sub classes also inherit this interface and are consequently serializable.
When serialization is unavoidable, it is possible that the class suffers from serializability issues. Usually, this happens when there are references to non-serializable objects within the serializable class. This compliant solution avoids the possibility of incorrect serialization and also protects sensitive data members from being 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 used.
| 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
}
}
}
|
Other solutions include using custom implementation of writeObject(), writeReplace() and writeExternal() methods 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 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 being serialized. This is the focus of the second noncompliant code example.
Noncompliant Code Example
| Wiki Markup |
|---|
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 serializable as it extends the {{Exception}} class that implements {{Serializable}}. (Based on \[[Bloch 2005|AA. Java References#Bloch 05]\]) |
| 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
Ideally, extending a class or interface that implements Serializable should be avoided. When this is not possible, undue serialization of the subclass can be prohibited by throwing a NotSerializableException from a custom writeObject() or readResolve() method, defined in the subclass SensitiveClass. It is also required to declare the methods final to prevent a malicious subclass from overriding them.
| Code Block | ||
|---|---|---|
| ||
class SensitiveClass extends Exception {
// ...
private final Object readResolve() throws NotSerializableException {
throw new NotSerializableException();
}
}
|
Risk Assessment
If sensitive data can be serialized, it may be transmitted over an insecure link, or stored in an insecure medium, or disclosed inappropriately.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
SER03- J | medium | likely | high | P6 | L2 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
| Wiki Markup |
|---|
\[[JLS 2005|AA. Java References#JLS 05]\] [Transient modifier|http://java.sun.com/docs/books/jls/third_edition/html/classes.html#37020] \[[SCG 2007|AA. Java References#SCG 07]\] Guideline 5-1 Guard sensitive data during serialization \[[Sun 2006|AA. Java References#Sun 06]\] "Serialization specification: A.4 Preventing Serialization of Sensitive Data" \[[Harold 1999|AA. Java References#Harold 99]\] \[[Long 2005|AA. Java References#Long 05]\] Section 2.4, Serialization \[[Greanier 2000|AA. Java References#Greanier 00]\] [Discover the secrets of the Java Serialization API|http://java.sun.com/developer/technicalArticles/Programming/serialization/] \[[Bloch 2005|AA. Java References#Bloch 05]\] Puzzle 83: Dyslexic Monotheism \[[Bloch 2001|AA. Java References#Bloch 01]\] Item 1: Enforce the singleton property with a private constructor \[[MITRE 2009|AA. Java References#MITRE 09]\] [CWE ID 502|http://cwe.mitre.org/data/definitions/502.html] "Deserialization of Untrusted Data", [CWE ID 499|http://cwe.mitre.org/data/definitions/499.html] "Serializable Class Containing Sensitive Data" |
SER02-J. Extendable classes should not declare readResolve() and writeReplace() private or static 18. Serialization (SER) SER04-J. Validate deserialized objects