...
Java language's access control mechanisms cease to remain effective after a class is serialized. Consequently, any sensitive data that was originally protected using access qualifiers (such as the private
keyword) gets exposed. Moreover, the security manager does not provide any checks to guarantee integrity of the serialized data.
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 } } 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);} } } |
Compliant Solutions
In the absence of sensitive data, a class can be serialized by 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 sub classes will also inherit this interface and will as a result be serializable.
...
Other solutions include custom implementation of writeObject
, writeReplace
and writeExternal
methods such that sensitive fields are not written to the serialized stream or alternatively, conducting proper validation checks while deserializing. Yet another remediation is to define the serialPersistentFields
array field and ensure that sensitive fields are not added to the array. 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.
Noncompliant Code Example
Wiki Markup |
---|
Serialization can also be used maliciously to return multiple instances of a singleton-like class. In this noncompliant example, a subclass {{SensitiveClass}} inadvertently becomes Serializable since it extends the {{Exception}} class that implements {{Serializable}}. (Based on \[[Bloch 05|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
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, one should avoid extending a class or interface that implements Serializable
.
Code Block | ||
---|---|---|
| ||
private Object readResolve() throws NotSerializableException { throw new NotSerializableException(); } |
Risk Assessment
If sensitive data can be serialized then it may be transmitted over an insecure link, or stored in an insecure medium, and thereby released inappropriately.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
FIO32-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 05|AA. Java References#JLS 05]\] [Transient modifier|http://java.sun.com/docs/books/jls/third_edition/html/classes.html#37020] \[[SCG 07|AA. Java References#SCG 07]\] Guideline 5-1 Guard sensitive data during serialization \[[Harold 99|AA. Java References#Harold 99]\] \[[Long 05|AA. Java References#Long 05]\] Section 2.4, Serialization \[[Greanier 00|AA. Java References#Greanier 00]\] [Discover the secrets of the Java Serialization API|http://java.sun.com/developer/technicalArticles/Programming/serialization/] \[[Bloch 05|AA. Java References#Bloch 05]\] Puzzle 83: Dyslexic Monotheism \[[Bloch 01|AA. Java References#Bloch 01]\] Item 1: Enforce the singleton property with a private constructor \[[MITRE 09|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" |
...