...
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 Date object:
| Code Block | ||
|---|---|---|
| ||
Performing a defensive copy before returning a reference to a mutable internal state ensures that the caller can only modify the copy and not the original internal state. Pugh \[[Pugh 2009|AA. Bibliography#Pugh 09]\] cites a vulnerability discovered by the Findbugs static analysis tool in the early betas of JDK 1.7 where the {{sun.security.x509.InvalidityDateExtension}} class returned a {{Date}} instance through a {{public}} accessor without creating defensive copies. h2. Noncompliant Code Example This noncompliant code example shows a {{getDate()}} accessor method that returns the sole instance of the {{private}} {{Date}} object. {code:bgColor=#FFcccc} class MutableClass { private Date d; public MutableClass() { d = new Date(); } public Date getDate() { return d; } } {code} |
An
...
untrusted
...
caller
...
can
...
manipulate
...
a
...
private
...
Date
...
object
...
because
...
returning
...
the
...
reference
...
exposes
...
the
...
internal
...
mutable
...
component
...
beyond
...
the
...
trust
...
boundaries
...
of
...
MutableClass
...
.
Compliant Solution (clone())
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.
| Code Block | ||
|---|---|---|
| ||
public}}) This compliant solution returns a clone of the {{Date}} object from the {{getDate()}} accessor method. This is safe because while {{Date}} can be extended by an attacker, the {{Date}} object returned by {{getDate()}} is controlled by {{MutableClass}} and is known not to be a malicious subclass. {code:bgColor=#ccccff} protected Date getDate() { return (Date)d.clone(); } {code} |
Note
...
that
...
defensive
...
copies
...
performed
...
during
...
execution
...
of
...
a
...
constructor
...
must
...
avoid
...
use
...
of
...
the
...
clone()
...
method
...
when
...
the
...
class
...
could
...
be
...
subclassed
...
by
...
...
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.
| Code Block | ||
|---|---|---|
| ||
}} method. For more details, see rule "[OBJ00-J. Limit extensibility of classes and methods with invariants to trusted subclasses only]." Classes that have {{public}} setter methods must follow the related advice found in rule "[FIO00-J. Defensively copy mutable inputs and mutable internal components|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. h2. 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 would be insufficient because an attacker can modify the {{Date}} objects in the array. {code:bgColor=#FFcccc} class MutableClass { private Date[] date; public MutableClass() { date = new Date[20]; for (int i = 0; i < 20date.length; i++) { date[i] = new Date(); } } public Date[] getDate() { return date; // orOr return date.clone() } } {code} h2. Compliant Solution |
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
...
Date objects:
| Code Block | ||
|---|---|---|
| ||
}} objects. {code:bgColor=#ccccff} class MutableClass { private Date[] date; public MutableClass() { date = new Date[20]; for(int i = 0; i < 20date.length; i++) { date[i] = new Date(); } } public Date[] getDate() { Date[] dates = new Date[20date.length]; for (int i = 0; i < 20date.length; i++) { dates[i] = (Date) date[i].clone(); } return dates; } } {code} h2. Noncompliant Code Example |
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
...
...
...
(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
...
...
| Code Block | ||||
|---|---|---|---|---|
| =
| |||
} class ReturnRef { // Internal state, may contain sensitive data private Hashtable<Integer,String> ht = new Hashtable<Integer,String>(); private ReturnRef() { ht.put(1, "123-45-6666"); } public Hashtable<Integer,String> getValues(){ return ht; } public static void main(String[] args) { ReturnRef rr = new ReturnRef(); Hashtable<Integer, String> ht1 = rr.getValues(); // Prints sensitive data 123-45-6666 ht1.remove(1); // Untrusted caller can remove entries Hashtable<Integer, String> ht2 = rr.getValues(); // Now prints null,; original entry is removed } } {code} |
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.
| Code Block | ||
|---|---|---|
| ||
collection. See rule "[OBJ11-J. Write garbage-collection-friendly code|OBJ15-J. Write garbage-collection-friendly code]" for more information. h2. 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. {code:bgColor=#ccccff} class ReturnRef { // ... private Hashtable<Integer,String> getValues(){ return (Hashtable<Integer, String>) ht.clone(); // shallowShallow copy } public static void main(String[] args) { ReturnRef rr = new ReturnRef(); // Prints nonsensitive data Hashtable<Integer,String> ht1 = rr.getValues(); // prints non-sensitive data Untrusted caller can only modify copy ht1.remove(1); // untrustedPrints caller can only modify copynonsensitive data Hashtable<Integer,String> ht2 = rr.getValues(); // prints non-sensitive data } } {code} |
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.
...
...
...
...
...
...
...
...
...
and OBJ04-J.
...
...
...
...
...
...
...
...
...
...
...
...
...
...
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 equals() and hashCode() methods. Mutable objects whose equals() or hashCode() method results may be modified are not suitable keys.
Exceptions
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.
Risk Assessment
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.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
OBJ05-J | High | Probable | Medium | P12 | L1 |
Automated Detection
Sound automated detection is infeasible; heuristic checks could be useful.
| Tool | Version | Checker | Description | ||||||
|---|---|---|---|---|---|---|---|---|---|
| Parasoft Jtest |
| CERT.OBJ05.CPCL CERT.OBJ05.MPT CERT.OBJ05.SMO CERT.OBJ05.MUCOP | 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 | ||||||
| SonarQube |
| S2384 | Mutable members should not be stored or returned directly Implemented for Arrays, Collections and Dates. |
Related Vulnerabilities
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.
Related Guidelines
CWE-375, Returning a Mutable Object to an Untrusted Caller |
Bibliography
[API 2014] | Method clone() |
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" | |
| [Pugh 2009] | |
...