Page History

A mutable input has the characteristic that its value may change between different accesses. Sometimes a method does not operate directly on the input parameter. This opens a window of opportunities opportunity for exploiting race conditions. A " time-of-check, time-of-use " (TOCTOU) inconsistency results when a field contains a value that passes the initial validation and security checks but mutates to a different value during actual usageuse.

Additionally, an object's state may get corrupted if it returns references to internal mutable components. Accessors must consequently return defensive copies of internal mutable objects. (OBJ37-J. Defensively copy private mutable class members before returning their references)

Noncompliant Code Example

A TOCTOU inconsistency exists in this noncompliant code sampleexample. Since As cookie is a mutable input, a malicious an attacker may cause the cookie to expire between the initial check and the actual use.

import java.net.HttpCookie;

public final class MutableDemo {

  // java.net.HttpCookie is mutable
  public void UseMutableInputuseMutableInput(HttpCookie cookie) {
    if (cookie == null) {
      throw new NullPointerException();
    }

    //check if cookie has expired
    if(cookie.hasExpired()) {
      //cookie is no longer valid, handle condition
    }

    doLogic(cookie);  //cookie Cookie may have expired since time of check resulting in
    // an exception
    doLogic(cookie);
  }
}

Compliant Solution

...

The problem is alleviated by creating a copy of the mutable input and using it to perform operations so that the original object is left unscathed. This can be realized by implementing the {{java.lang.Cloneable}} interface and declaring a {{public}} clone method or by using a copy constructor. Performing a manual copy of object state within the caller becomes necessary if the mutable class is declared {{final}} (that is, it cannot provide an accessible copy method) . (See \[[Guideline 2-1 Create a copy of mutable inputs and outputs|http://java.sun.com/security/seccodeguide.html]\].) Note that the input validation must follow after the creation of the copy(OBJ36-J. Provide mutable classes with a clone method to allow passing instances to untrusted code safely). Note that any input validation must be performed on the copy and not the original object.

Code Block
bgColor #ccccff
import java.net.HttpCookie; public final class MutableDemo { // java.net.HttpCookie is mutable public void copyMutableInputuseMutableInput(HttpCookie cookie) { if (cookie == null) { throw new NullPointerException(); } // create copy cookie = (HttpCookie)cookie.clone(); //check if cookie has expired if(cookie.hasExpired()) { //cookie is no longer valid, handle condition } doLogic(cookie); } }

...

In order to copy mutable inputs having a non-final type, create a new instance of the ArrayList. This instance can now be forwarded to any trusted code capable of modifying it.

...

Code Block
bgColor #ccccff
public void copyInterfaceInput(Collection<String> collection) { // convert input to trusted implementation collection = new ArrayList(collection); doLogic(collection); }

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 the 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;
  }
}

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. 

Compliant Solution

Do not carry out defensive copying using the clone() method in constructors, where 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.

Despite this advice, this compliant solution recommends returning a clone of the Date object. While this should not be done in constructors, it is permissible to use it in accessors. This is because there is no danger of a malicious subclass extending the internal mutable Date object.

protected Date getDate() {
  return (Date)d.clone();
}

Risk Assessment

Failing to create a copy of a mutable input may enable an attacker to exploit a TOCTOU vulnerability and at other times, expose internal mutable components to untrusted code.

...