Page History

...

Pugh \[[Pugh 09|AA. Java References#Pugh 09]\] cites a vulnerability discovered by the Findbugs static analysis tool in the early betas of jdk 1.7. The class {{sun.security.x509.InvalidityDateExtension}} returned a {{Date}} instance through a {{public}} accessor, without creating defensive copies.

Noncompliant Code Example

This noncompliant code example defines a class that contains a private Hashtable instance field. Here, the hash table itself is designed to hold immutable data of sensitive nature (SSN numbers). A getter method getValues() gives the caller access to the hash table by returning a reference to it. When invoked by untrusted code, entries may be maliciously added, removed or replaced.

class ReturnRef {
  // Internal state, may contain sensitive data
  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
  }	
}

Compliant Solution

Do not provide a getter method like getValues() that exposes private internal object state. This applies largely to members containing mutable as well as immutable data. Deep copies of mutable data are required to be returned whereas it suffices to return shallow copies of mutable fields containing immutable data.

...

If the hash table contained references to mutable data such as a series of Date objects, every one of those objects must be copied by using a copy constructor or method. For further details, refer to FIO31-J. Defensively copy mutable inputs and mutable internal components and OBJ10-J. Provide mutable classes with a clone method to allow passing instances to untrusted code safely. Note that the keys of a hash table need not be deep copied; shallow copying of the references suffices because a hash table's contract dictates that it cannot hold duplicate keys.

Noncompliant Code Example

This noncompliant code example shows a getDate() accessor method that returns the sole instance of the private Date object. An untrusted caller will be able to manipulate this instance as it exposes internal mutable components beyond the trust boundaries of the class.

class MutableClass {
  private Date d;

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

  protected Date getDate() {
    return d;
  }
}

Compliant Solution

Do not carry out defensive copying using the clone() method in constructors, when the (non-system) class can be subclassed by untrusted code. This will limit the malicious code from returning a crafted object when the object's clone() method is invoked.

...

If the class has a public setter method, this guideline still applies. Note that a setter method may perform input validation and sanitization before setting the internal fields. On the other hand, returning references to internal objects may require the caller to incorporate none of these defensive measures.

Exceptions

*EX1:* According to Sun's Secure Coding Guidelines document \[[SCG 07|AA. Java References#SCG 07]\]:

...

EX3: If the caller exposes an unmodifiable view of the object, it may not be required to defensively program the class to return copies of internal members. This decision should be made early in the design of the API. Note that if some other code wants to use this class in the future, it must also expose unmodifiable views. (SEC14-J. Provide sensitive mutable classes with unmodifiable wrappers)

Risk Assessment

Returning references to internal object state (mutable or immutable) can render an application susceptible to information leaks and corrupt the object's state and violate any class invariants. Control flow may also be affected in some cases.

Automated Detection

TODO

Related Vulnerabilities

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

Other Languages

This rule appears in the C++ Secure Coding Standard as OBJ35-CPP. Do not return references to private data.

References

\[[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
\[[SCG 07|AA. Java References#SCG 07]\] Guideline 2-1 Create a copy of mutable inputs and outputs
\[[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
\[[Gong 03|AA. Java References#Gong 03]\] 9.4 Private Object State and Object Immutability
\[[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"

...