A mutable input has the characteristic that its value may vary; that is, multiple accesses may see differing values. This characteristic enables potential attacks that exploit race conditions. For example, a time-of-check, time-of-use (TOCTOU) vulnerability may result when a field contains a value that passes validation and security checks but changes before use.
Returning references to an object's internal mutable components provides an attacker with the opportunity to corrupt the state of the object. Consequently, accessor methods must return defensive copies of internal mutable objects (see OBJ05-J. Do not return references to private mutable class members for more information).
Noncompliant Code Example
This noncompliant code example contains a TOCTOU vulnerability. Because
cookie is a mutable input, an attacker can cause it to expire between the initial check (the
hasExpired() call) and the actual use (the
This compliant solution avoids the TOCTOU vulnerability by copying the mutable input and performing all operations on the copy. Consequently, an attacker's changes to the mutable input cannot affect the copy. Acceptable techniques include using a copy constructor or implementing the
java.lang.Cloneable interface and declaring a public
clone() method (for classes not declared final). In cases such as
HttpCookie where the mutable class is declared final—that is, it cannot provide an accessible copy method—perform a manual copy of the object state within the caller (see OBJ04-J. Provide mutable classes with copy functionality to safely allow passing instances to untrusted code for more information). Note that any input validation must be performed on the copy rather than on the original object.
Some copy constructors and
clone() methods perform a shallow copy of the original instance. For example, invocation of
clone() on an array results in creation of an array instance whose elements have the same values as the original instance. This shallow copy is sufficient for arrays of primitive types but fails to protect against TOCTOU vulnerabilities when the elements are references to mutable objects, such as an array of cookies. Such cases require a deep copy that also duplicates the reference objects.
This compliant solution demonstrates correct use both of a shallow copy (for the array of
int) and of a deep copy (for the array of cookies):
Noncompliant Code Example
When the class of a mutable input is nonfinal or is an interface, an attacker can write a subclass that maliciously overrides the parent class's
clone() method. The attacker's
clone() method can subsequently subvert defensive copying. This noncompliant code example demonstrates this weakness:
This compliant solution protects against potential malicious overriding by creating a new instance of the nonfinal mutable input, using the expected class rather than the class of the potentially malicious argument. The newly created instance can be forwarded to any code capable of modifying it.
Some objects appear to be immutable because they have no mutator methods. For example, the
java.lang.CharSequence interface describes an immutable sequence of characters. Note, however, that a variable of type
CharSequence is a reference to an underlying object of some other class that implements the
CharSequence interface; that other class may be mutable. When the underlying object changes, the
CharSequence changes. Essentially, the
java.lang.CharSequence interface omits methods that would permit object mutation through that interface but lacks any guarantee of true immutability. Such objects must still be defensively copied before use. For the case of the
java.lang.CharSequence interface, one permissible approach is to obtain an immutable copy of the characters by using the
toString() method. Mutable fields should not be stored in static variables. When there is no other alternative, create defensive copies of the fields to avoid exposing them to untrusted code.
|Enforce returning a defensive copy in 'clone()' methods|
Do not pass user-given mutable objects directly to certain types
Do not store user-given mutable objects directly into variables
Provide mutable classes with copy functionality
Implemented for Arrays, Collections and Dates.
CVE-2012-0507 describes an exploit that managed to bypass Java's applet security sandbox and run malicious code on a remote user's machine. The exploit created a data structure that is normally impossible to create in Java but was built using deserialization, and the deserialization process did not perform defensive copies of the deserialized data. See the code examples in SER07-J. Do not use the default serialized form for classes with implementation-defined invariants for more information.
Guideline 6-2 / MUTABLE-2: Create copies of mutable output values
Item 39, "Make Defensive Copies When Needed"
"Returning References to Internal Mutable State"