Page History

Returning references to internal mutable members of a class can compromise an application's security, both by breaking encapsulation and also by providing the opportunity to corrupt the internal state of the class (whether accidentally or maliciously). Therefore, programs must not return references to internal mutable classes.

Returning a reference to a defensive copy of a reference to a mutable internal state ensures that the caller can only modify the copy and not cannot modify the original internal state, although the copy remains mutable.

Noncompliant Code Example

...

This compliant solution returns a clone of the Date object from the getDate() accessor method. This is safe because while 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 not to be a malicious nonmalicious subclass.

protected 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 " 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 " 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.

...

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 is insufficient because an attacker can modify the Date objects in the array.

...

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 getValues() gives the caller access to the hash table by returning a reference to it. An untrusted caller can use the getter 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 can be performed by multiple threads, providing ample opportunities for race conditions.

...

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();
    Hashtable<Integer,String> ht1 = rr.getValues(); // prints non-sensitive data
    Hashtable<Integer,String> ht1 = rr.removegetValues(1); 
    // untrusted caller can only modify copy
                   ht1.remove(1); 
    // untrustedprints caller can only modify copynon-sensitive data
    Hashtable<Integer,String> ht2 = rr.getValues(); // prints non-sensitive data
  }
}

When a hash table contains references to mutable data such as a series of Date objects, each of those objects must also be copied by using a copy constructor or method. For further details, refer to rules "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."

Note that making deep copies of the keys of a hash table do not need to be deep copiedis 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. Mutable objects whose equals() or hashCode() method results may be modified are not suitable keys.

...

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.

...

Bibliography

...