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 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 manager 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

...

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). (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.

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

At timesSometimes, 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 here: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. (See \[[Guideline 2-1 Create a copy of mutable inputs and outputs|http://java.sun.com/security/seccodeguide.html]\].) In order to copy mutable inputs having a non-final or interface type, the following approaches may be employedThis 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 collection) {
  // convert input to trusted implementation
  collection = new ArrayList(collection);
  doLogic(collection);
}

Exceptions

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 EX1: It is allowable to forgo defensive copying using the clone() method in cases where the (non-system) class can be subclassed by untrusted code. This is because will stop the malicious code may return 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. Even though class java.util.Date is not final, this is permissible as it is a trusted system class and it is not possible for a subclass to return an untrusted instance in its place.

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.

...