Page History

A mutable input has the characteristic that its value may change between different accesses. This opens a window of opportunity for exploiting race conditions. A vary; that is, multiple accesses may see differing values. This characteristic enables potential attacks that exploit race conditions. For example, 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 use.

Additionally, returning references to an an object's state may get corrupted if it returns references to internal mutable components . Accessors affords an attacker with the opportunity to corrupt the state of the object. Accessor methods must consequently return defensive copies of internal mutable objects. (See ; see guideline OBJ11-J. Defensively copy private mutable class members before returning their references for additional information.)

Noncompliant Code Example

A TOCTOU inconsistency exists in this This noncompliant code example contains a TOCTOU inconsistency. As Because cookie is a mutable input, an attacker may can 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 ifwhether cookie has expired
    if (cookie.hasExpired()) {
      // Cookie is no longer valid, handle condition by throwing an exception
    }

    // Cookie may have expired since time of check 
    doLogic(cookie);
  }
}

Compliant Solution

The problem is alleviated by creating a copy of This compliant solution avoids the TOCTOU vulnerability by copying the mutable input and using it to then perform operations so that the original object is left unscathed. This can be realized by all operations on the copy. Consequently, an attacker's changes to the mutable input cannot affect copy. Acceptable techniques include using a copy constructor or implementing the java.lang.Cloneable interface and declaring a public clone method if the class is final or by using a copy constructor. Performing a manual copy of the object state within the caller becomes necessary if the (for classes not declared as final. In cases where the mutable class is declared final. That — that is, it cannot provide an accessible copy method — perform a manual copy of the object state within the caller. See the guideline OBJ10-J. Provide mutable classes with copy functionality to allow passing instances to untrusted code safely for more information. Note that any input validation must be performed on the copy and not on the original object.

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

    // Create copy
    cookie = (HttpCookie)cookie.clone();

    // Check ifwhether cookie has expired
    if (cookie.hasExpired()) {
      // Cookie is no longer valid, handle condition by throwing an exception
    }

    doLogic(cookie);
  }
}

Compliant Solution

Sometimes, the copy constructor or the You must make defensive copies of all mutable inputs to comply with this guideline. Some copy constructors and clone() method returns methods perform 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 whose elements have the same elements values as the original instance. However, This shallow copy is sufficient for arrays of primitive types, but fails to protect against TOCTOU vulnerabilities when the elements are references to mutable objects. Use a deep copy that involves performs element duplication is required when the input consists of mutable components, such as an array of cookies.

This compliant solution exemplifies this conditiondemonstrates correct use of both a shallow copy (for the array of {{int}}s) and a deep copy (for the array of cookies).

  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 class of the a mutable input type is non-final, an attacker can write a malicious subclass may maliciously override its that maliciously overrides the parent class's clone() method. This is a serious issue unless the non-final input defends against itThe attacker's clone() method could then subvert defensive copying. This noncompliant code example demonstrates this the weakness.

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

Compliant Solution

To copy mutable inputs having a This compliant solution protects against potential malicious overriding by creating a new instance of the non-final type, create a new instance of the ArrayList. This mutable input, using the expected class rather than the actual class of the provided object. The newly created instance can be forwarded to any code capable of modifying it.

...

Some objects appear to be immutable because they have no mutator methods. For example, the java.lang.CharacterSequence interface describes an immutable sequence of characters. It should be noted that if the underlying implementation on which the CharacterSequence is based changes, the value of the CharacterSequence also changesNote, however, that a variable of type CharacterSequence is a reference to an underlying object of some other class that implements the CharacterSequence interface; that other class may be mutable. When the underlying object changes, the CharacterSequence changes. Essentially, the java.lang.CharacterSequence interface omits methods that would permit object mutation through that interface, but lacks any guarantee of true immutability. Such objects must be defensively copied before use. It is also permissible to use the toString() method to make them immutable before passing them as parameters. Mutable fields should not be stored in static variables. When there is no other alternative, create defensive copies of the fields to avoid exposing them to untrusted code.

...

Bibliography

\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 2-1 Create a copy of mutable inputs and outputs
\[[Bloch 2008|AA. Bibliography#Bloch 08]\] Item 39: Make defensive copies when needed
\[[Pugh 2009|AA. Bibliography#Pugh 09]\] Returning references to internal mutable state
\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 2-1 Create a copy of mutable inputs and outputs

...

09. Input Output (FIO)      09. Input Output (FIO)      FIO01-J. Do not expose buffers created using the wrap() or duplicate() methods to untrusted code