Page History

Returning references to internal object state (mutable or immutable fields and members, alike) can seriously compromise the security of an application because of the resulting sub par encapsulation properties and susceptibility to corruption of the class invariants inflicted by the clients of the code.

Noncompliant Code Example

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:

class MutableClass {
  private Date d;

  public MutableClass() {
    d = new Date();
  }

  public Date getDate() {
    return d;
  }
}

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.

public 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 (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.

class MutableClass {
  private Date[] date;

  public MutableClass() {
    date = new Date[20];
    for (int i = 0; i < date.length; i++) {
      date[i] = new Date();
    }
  }

  public Date[] getDate() {
    return date; // Or return date.clone()
  }
}

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:

class MutableClass {
  private Date[] date;

  public MutableClass() {
    date = new Date[20];
    for(int i = 0; i < date.length; i++) {
      date[i] = new Date();
    }
  }

  public Date[] getDate() {
    Date[] dates = new Date[date.length];
    for (int i = 0; i < date.length; i++) {
      dates[i] = (Date) date[i].clone();
    }
    return dates;
  }
}

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 This noncompliant piece of code defines a class that contains a Hashtable instance field. Here, the hash table itself is designed to hold immutable data of sensitive nature (ssn numbers). A getter method getValues() is also provided to give the caller access to the hash table by returning a reference to it. This is dangerous since hostile code can surreptitiously view the contents of the object's private data. Not only that, it can also add, remove or modify the hash table entries at its willAn 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.

class ReturnRef {
  // internalInternal state, may contain sensitive data
  private Hashtable<Integer,String> ht = new Hashtable<Integer,String>(); 
 
  private ReturnRef() {
    ht.put(1, "123-45-6666");
  }
 
  privatepublic Hashtable<Integer,String> getValues(){
    System.out.println(ht.get(1));    
    return ht;
  }
 
  public static void main(String[] args) {
    ReturnRef rr = new ReturnRef();
    Hashtable<Integer, String> ht1 = rr.getValues(); // printsPrints sensitive data 123-45-6666
    ht1.remove(1);                                   // untrustedUntrusted caller can remove entries
    Hashtable<Integer, String> ht2 = rr.getValues(); // nowNow prints null,; original entry is removed!
  }	
}

Compliant Solution

Do not provide a getter method like getValues() that exposes private internal object state. This applies to both mutable as well as immutable instance fields and objects. The former can allow untrusted code to alter the state of the object while the latter can leak private information by breaking the encapsulation property.

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 If some internal object contains immutable data that is not of sensitive nature, create and return its shallow copy as the caller cannot modify the originally referenced data. This solution highlights how a shallow copy of the internal hash table can be created and returned. Ergo, attempts to modify containing immutable SSNs. Consequently, the original hash table run into a dry stretchremains private, and any attempts to modify it are ineffective.

class ReturnRef {
  // ...
  private Hashtable<Integer,String> getValues(){
  System.out.println(ht.get(1));
  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 dataUntrusted caller can only modify copy
    ht1.remove(1); //
 untrusted caller can remove// entriesPrints onlynonsensitive fromdata
 the copy
  Hashtable<Integer,String> ht2 = rr.getValues(); //
 prints non sensitive data      }
}

At other times, a deep copy may be desirable. This condition applies to all objects whose state comprises mutable data. For instance, if the hash table contained When a hash table contains references to mutable data such as a series of Date objects, every one each of those objects will have to must also be copied by using a copy constructor or method . For further details, (refer to FIO31 OBJ06-J. Defensively copy mutable inputs and mutable internal components and OBJ36OBJ04-J. Provide mutable classes with a clone method. Note that 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 need not be deep copiedis unnecessary; shallow copying of the references suffices since because a hash table's contract dictates that it cannot hold duplicate keysits 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 leakage and corrupt the object's state and leaks and corruption of its objects' states, which consequently violates class invariants. Control flow may can also be affected in dire some cases.

Automated Detection

...

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Other Languages

...

Sound automated detection is infeasible; heuristic checks could be useful.

Tool	Version	Checker	Description
Parasoft Jtest	Include Page Parasoft_V Parasoft_V	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	Include Page SonarQube_V SonarQube_V	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

...

...

\[[API 06|AA. Java References#API 06]\] [method clone()|http://java.sun.com/javase/6/docs/api/java/lang/Object.html#clone()]
\[[Security 06|AA. Java References#Security 06]\]
\[[Bloch 08|AA. Java References#Bloch 08]\] Item 39: Make defensive copies when needed
\[[Haggar 00|AA. Java References#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]
\[[Goetz 06|AA. Java References#Goetz 06]\] 3.2. Publication and Escape: Allowing Internal Mutable State to Escape
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 375|http://cwe.mitre.org/data/definitions/375.html] "Passing Mutable Objects to an Untrusted Method"

Bibliography

...

Image Added Image Added Image AddedOBJ36-J. Provide mutable classes with a clone method      07. Object Orientation (OBJ)      07. Object Orientation (OBJ)