FIO31-J. Create a copy of mutable inputs

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 for exploiting race conditions. A "time-of-check, time-of-use" (TOCTOU) inconsistency results when a field contains a value that passes the initial security manager checks but mutates to a different value during actual usage.

Noncompliant Code Example

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

public final class MutableDemo {

  // java.net.HttpCookie is mutable
  public void UseMutableInput(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 may have expired since time of check resulting in an exception
  }
}

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 as final (that is, it cannot provide an accessible copy method)xyz. Note that the input validation must follow after the creation of the copy.

public final class MutableDemo {

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

    // create copy
    cookie = cookie.clone();

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

    doLogic(cookie);
  }
}

At times, the copy constructor or the clone method returns a shallow copy of the original instance. For example, invocation of clone() on an array results in creation of an array instance that shares references to the same elements as the original instance. A deep copy that involves element duplication can be created as shown below.

  public void deepCopy(int[] ints, HttpCookie[] cookies) {
    if (ints == null || cookies == null) {
      throw new NullPointerException();
    }

    // shallow copy
    int[] intsCopy = ints.clone();

    // deep copy
    HttpCookie[] cookiesCopy = new HttpCookie[cookies.length];

    for (int i = 0; i < cookies.length; i++) {
      // manually create copy of each element in array
      cookiesCopy[i] = cookies[i].clone();
    }
 
    doLogic(intsCopy, cookiesCopy);
}

When the mutable input type is non-final, a malicious subclass may override the clone method. This is a serious issue unless the non-final input defends against it See xyz. In order to copy mutable inputs having a non-final or interface type, the following approaches may be employed.

// java.util.ArrayList is mutable and non-final
public void copyNonFinalInput(ArrayList list) {
  // create new instance of declared input type 
  list = new ArrayList(list);
  doLogic(list);
}

// java.util.Collection is an interface
public void copyInterfaceInput(Collection collection) {
  // convert input to trusted implementation
  collection = new ArrayList(collection);
  doLogic(collection);
}

Risk Assessment

Failing to create a copy of a mutable input may enable an attacker to exploit a TOCTOU vulnerability.

Automated Detection

TODO

Related Vulnerabilities

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

References

[[SCG 07]] Guideline 2-2 Support copy functionality for a mutable class