Serialized objects can be altered outside of any Java program unless they are protected using mechanisms such as sealing and signing. (See ENV01-J. Place all security-sensitive code in a single JAR and sign and seal it.) If an object referring to a system resource becomes serialized, and an attacker can alter the serialized form of the object, it becomes possible to modify the system resource that the serialized handle refers to. For example, an attacker may modify a serialized file handle to refer to an arbitrary file on the system. In the absence of a security manager, any operations that use the file handle will be carried out using the attacker-supplied file path and file name.
Noncompliant Code Example
This noncompliant code example declares a serializable
File object in the class
The serialized form of the object exposes the file path, which can be altered. When the object is deserialized, the operations are performed using the altered path, which can cause the wrong file to be read or modified.
Compliant Solution (Not Implementing Serializable)
This compliant solution shows a
Ser that does not implement
java.io.Serializable. Consequently, the
File object cannot be serialized.
Compliant Solution (Object Marked Transient)
This compliant solution declares the
transient. The file path is not serialized with the rest of the class and consequently is not exposed to attackers.
Deserializing direct handles to system resources can allow the modification of the resources being referred to.