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). ThereforeAs a result, programs must not return references to internal mutable classes.
...
This noncompliant code example shows a getDate()
accessor method that returns the sole instance of the private Date
object.
Code Block | ||
---|---|---|
| ||
class MutableClass { private Date d; public MutableClass() { d = new Date(); } public Date getDate() { return d; } } |
...
This compliant solution returns a clone of the Date
object from the getDate()
accessor method. While Date
can be extended by an attacker, this is safe because the Date
object returned by getDate()
is controlled by MutableClass
and is known to be a nonmalicious subclass.
Code Block | ||
---|---|---|
| ||
protectedpublic Date getDate() { return (Date)d.clone(); } |
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. For more details, see rule OBJ00OBJ07-J. Limit extensibility of classes and methods with invariants to trusted subclasses only."
Classes that have public setter methods, that is, methods whose purpose is to change class fields, must follow the related advice found in rule 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.
...
Code Block | ||
---|---|---|
| ||
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; // or return date.clone() } } |
...
Code Block | ||
---|---|---|
| ||
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; } } |
...
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). A getter method The getValues()
method gives the caller access to the hash table by returning a reference to it. An untrusted caller can use the getter 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.
...
Code Block | ||
---|---|---|
| ||
class ReturnRef { // ... private Hashtable<Integer,String> getValues(){ return (Hashtable<Integer, String>) ht.clone(); // shallow copy } public static void main(String[] args) { ReturnRef rr = new ReturnRef(); // printsPrints non-sensitive data Hashtable<Integer,String> ht1 = rr.getValues(); // untrustedUntrusted caller can only modify copy ht1.remove(1); // printsPrints non-sensitive data Hashtable<Integer,String> ht2 = rr.getValues(); } } |
...
Note that making deep copies of the keys of a hash table is unncessary; 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()
functions methods. Mutable objects whose equals()
or hashCode()
method results may be modified are not suitable keys.
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="e261b45f9fe8815c-c11a3148-4ac94c94-8328b4b5-63db2220ca8b8a65f7f29ec1"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API 06]] | [Method | http://java.sun.com/javase/6/docs/api/java/lang/Object.html#clone()] | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="b10b826ab53c471c-e2fa75e7-4a344b20-bd39888d-c104d2db4d7cbd65d35f3dd0"><ac:plain-text-body><![CDATA[ | [[Bloch 2008 | AA. Bibliography#Bloch 08]] | Item 39. Make defensive copies when needed | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="cd6af327a929aad9-d48f99d4-4b474dd9-8ce28964-16a6053870f3541708f33546"><ac:plain-text-body><![CDATA[ | [[Goetz 2006 | AA. Bibliography#Goetz 06]] | 3.2, Publication and Escape: Allowing Internal Mutable State to Escape | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="f7dec2ff87b7e0e5-069a616d-485d4ac5-92a39e6c-554e543a2e84e9ab4b898c40"><ac:plain-text-body><![CDATA[ | [[Gong 2003 | AA. Bibliography#Gong 03]] | 9.4, Private Object State and Object Immutability | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="2b0d846ebfe0527b-c568d04b-4b0d475c-ac768901-55f9ecbfca545f52d9d82bb0"><ac:plain-text-body><![CDATA[ | [[Haggar 2000 | AA. Bibliography#Haggar 00]] | [Practical Java Praxis 64. Use clone for immutable objects when passing or receiving object references to mutable objects | http://www.informit.com/articles/article.aspx?p=20530] | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="69f63f3fe8634601-fd952f14-40714307-be8dae11-bb48f4048064309e3814011d"><ac:plain-text-body><![CDATA[ | [[Security 2006 | AA. Bibliography#Security 06]] |
| ]]></ac:plain-text-body></ac:structured-macro> |
...