Although serialization allows an object's state to be saved as a sequence of bytes and then reconstituted at a later time, it provides no mechanism to protect the serialized data. An attacker who gains access to the serialized data can use it to discover sensitive information and to determine implementation details of the objects. An attacker can also modify the serialized data in an attempt to compromise the system when the malicious data is deserialized. Consequently, sensitive data that is serialized is potentially exposed, without regard to the access qualifiers (such as the
private keyword) that were used in the original code. Moreover, the security manager cannot guarantee the integrity of the deserialized data.
Examples of sensitive data that should never be serialized include cryptographic keys, digital certificates, and classes that may hold references to sensitive data at the time of serialization.
This rule is meant to prevent the unintentional serialization of sensitive information. SER02-J. Sign then seal objects before sending them outside a trust boundary applies to the intentional serialization of sensitive information.
Noncompliant Code Example
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.
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 subclasses also inherit this interface and are consequently serializable. This approach is inappropriate for any class that contains sensitive data.
When serializing a class that contains sensitive data, programs must ensure that sensitive data is omitted from the serialized form. This includes suppressing both serialization of data members that contain sensitive data and serialization of references to nonserializable or sensitive objects.
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.
Other compliant solutions include
- Developing custom implementations of the
writeExternal()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 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
See MSC07-J. Prevent multiple instantiations of singleton objects for more information about singleton classes.
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
readObjectNoData() methods, defined in the nonserializable subclass. These custom methods must be declared private (see SER01-J. Do not deviate from the proper signatures of serialization methods for more information).
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).
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.
Serialization Not Disabled (Java)
|CERT.SER03.SIF||Inspect instance fields of serializable objects to make sure they will not expose sensitive information|
Guideline 8-2 / SERIAL-2: Guard sensitive data during serialization
Puzzle 83, "Dyslexic monotheism"
Item 1, "Enforce the Singleton Property with a Private Constructor"
Section 2.4, "Serialization"
Serialization Specification, A.4, Preventing Serialization of Sensitive Data