...
This rule is meant to prevent the unintentional serialization of sensitive information. SER02-J. Sign then seal sensitive objects before sending them outside a trust boundary applies to the intentional serialization of sensitive information.
...
| Code Block | ||
|---|---|---|
| ||
public class Point implements Serializable { 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 } } } } } |
...
| Code Block | ||
|---|---|---|
| ||
public class Point implements Serializable { 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 } } } } } |
...
It is still possible for an attacker to obtain uninitialized instances of SensitiveClass by catching NotSerializableException or by using a finalizer attack (see OBJ11-J. Be wary of letting constructors throw exceptions for more information). Consequently, an unserializable class that extends a serializable class must always validate its invariants before executing any methods. That is, any object of such a class must inspect its fields, its actual type (to prevent it being a malicious subclass), and any invariants it possesses (such as being a malicious second object of a singleton class).
Exceptions
SER03-J-EX0: Sensitive data that has been properly encrypted may be serialized.
...
If sensitive data can be serialized, it may be transmitted over an insecure connection, stored in an insecure location, or disclosed inappropriately.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
SER03-J | Medium | Likely | High | P6 | L2 |
Automated Detection
Tool | Version | Checker | Description | ||||||
|---|---|---|---|---|---|---|---|---|---|
| CodeSonar |
| JAVA.CLASS.SER.ND | Serialization Not Disabled (Java) | ||||||
| Coverity | 7.5 | UNSAFE_DESERIALIZATION | Implemented | ||||||
| Parasoft Jtest |
| CERT.SER03.SIF | Inspect instance fields of serializable objects to make sure they will not expose sensitive information |
Related Guidelines
CWE-499, Serializable Class Containing Sensitive Data | |
Guideline 8-2 / SERIAL-2: Guard sensitive data during serialization |
Bibliography
Puzzle 83, "Dyslexic monotheism" | |
Item 1, "Enforce the Singleton Property with a Private Constructor" | |
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