Returning references to internal mutable members of a class can compromise an application's security, both by breaking encapsulation and by providing the opportunity to corrupt the internal state of the class (whether accidentally or maliciously). As a result, programs must not return references to private mutable classes.
See rule OBJ13-J. Ensure that references to mutable objects are not exposed for details about leaking references to non-private objects.
Noncompliant Code Example
This noncompliant code example shows a
getDate() accessor method that returns the sole instance of the private
An untrusted caller can manipulate a private
Date object because returning the reference exposes the internal mutable component beyond the trust boundaries of
Compliant Solution (
Returning a reference to a defensive copy of a mutable internal state ensures that the caller cannot modify the original internal state, although the copy remains mutable. This compliant solution returns a clone of the
Date object from the
getDate() accessor method. Although
Date can be extended by an attacker, this approach is safe because the
Date object returned by
getDate() is controlled by
MutableClass and is known to be a nonmalicious subclass.
Note that defensive copies performed during execution of a constructor must avoid use of the
clone() method when the class could be subclassed by untrusted code. This restriction prevents execution of a maliciously crafted overriding of the
clone() method (see OBJ07-J. Sensitive classes must not let themselves be copied for more details).
Classes that have public setter methods, that is, methods whose purpose is to change class fields, must follow the related advice found in OBJ06-J. Defensively copy mutable inputs and mutable internal components. Note that setter methods can (and usually should) perform input validation and sanitization before setting internal fields.
Noncompliant Code Example (Mutable Member Array)
In this noncompliant code example, the
getDate() accessor method returns an array of
Date objects. The method fails to make a defensive copy of the array before returning it. Because the array contains references to
Date objects that are mutable, a shallow copy of the array is insufficient because an attacker can modify the
Date objects in the array.
Compliant Solution (Deep Copy)
This compliant solution creates a deep copy of the
date array and returns the copy, thereby protecting both the
date array and the individual
Noncompliant Code Example (Mutable Member Containing Immutable Objects)
In this noncompliant code example, class
ReturnRef contains a private
Hashtable instance field. The hash table stores immutable but sensitive data (for example, social security numbers [SSNs]). The
getValues() method gives the caller access to the hash table by returning a reference to it. An untrusted caller can use this method to gain access to the hash table; as a result, hash table entries can be maliciously added, removed, or replaced. Furthermore, multiple threads can perform these modifications, providing ample opportunities for race conditions.
In returning a reference to the
ht hash table, this example also hinders efficient garbage collection.
Compliant Solution (Shallow Copy)
Make defensive copies of private internal mutable object state. For mutable fields that contain immutable data, a shallow copy is sufficient. Fields that refer to mutable data generally require a deep copy.
This compliant solution creates and returns a shallow copy of the hash table containing immutable SSNs. Consequently, the original hash table remains private, and any attempts to modify it are ineffective.
When a hash table contains references to mutable data such as
Date objects, each of those objects must also be copied by using a copy constructor or method (refer to OBJ06-J. Defensively copy mutable inputs and mutable internal components and OBJ04-J. Provide mutable classes with copy functionality to safely allow passing instances to untrusted code for further details).
Note that making deep copies of the keys of a hash table is unnecessary; shallow copying of the references suffices because a hash table's contract dictates that its keys must produce consistent results to the
hashCode() methods. Mutable objects whose
hashCode() method results may be modified are not suitable keys.
OBJ05-J-EX0: When a method is called with only an immutable view of an object, that method may freely use the immutable view without defensive copying. This decision should be made early in the design of the API. Note that new callers of such methods must also expose only immutable views.
Returning references to internal object state (mutable or immutable) can render an application susceptible to information leaks and corruption of its objects' states, which consequently violates class invariants. Control flow can also be affected in some cases.
Sound automated detection is infeasible; heuristic checks could be useful.
|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.
Pugh [Pugh 2009] cites a vulnerability discovered by the Findbugs static analysis tool in the early betas of JDK 1.7 in which the
sun.security.x509.InvalidityDateExtension class returned a
Date instance through a
public accessor without creating defensive copies.
CWE-375, Returning a Mutable Object to an Untrusted Caller
Item 39, "Make Defensive Copies When Needed"
Section 3.2, "Publication and Escape: Allowing Internal Mutable State to Escape"
Section 9.4, "Private Object State and Object Immutability"