FIO31-J. Defensively copy mutable inputs and mutable internal components

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 validation and security checks but mutates to a different value during actual usage.

Additionally, an object's state may get corrupted if it returns references to internal mutable components. Accessors must therefore return defensive copies of internal mutable objects.

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.

import java.net.HttpCookie;

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 final (that is, it cannot provide an accessible copy method). (See [Guideline 2-1 Create a copy of mutable inputs and outputs].) Note that the input validation must follow after the creation of the copy.

import java.net.HttpCookie;

public final class MutableDemo {

  // java.net.HttpCookie is mutable
  public void copyMutableInput(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);
  }
}

Sometimes, 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 next.

  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] = (HttpCookie)cookies[i].clone();
    }
 
    doLogic(intsCopy, cookiesCopy);
}

Noncompliant Code Example

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. This noncompliant example shows such a vulnerable code snippet.

// java.util.ArrayList is mutable and non-final
public void copyNonFinalInput(ArrayList list) {
  doLogic(list);
}

Compliant Solution

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.

// 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);
}

Noncompliant Code Example

This noncompliant code example uses the Collection interface as an input parameter and directly passes it to doLogic().

// java.util.Collection is an interface
public void copyInterfaceInput(Collection<String> collection) {
  doLogic(collection);
}

Compliant Solution

This compliant solution instantiates a new ArrayList and forwards it to the doLogic method.

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

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 component to untrusted code.

Automated Detection

TODO

Related Vulnerabilities

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

References

[[SCG 07]] Guideline 2-1 Create a copy of mutable inputs and outputs
[[Bloch 08]] Item 39: Make defensive copies when needed

FIO07-J. Do not assume infinite heap space      07. Input Output (FIO)      SER30-J. Do not serialize sensitive data