Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: done

A mutable input has the characteristic that its value may 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 vulnerability may result when a field contains a value that passes initial validation and security checks but mutates to a different value during actual changes before use.

Additionally, returning Returning references to an an object's internal mutable components provides an attacker with the opportunity to corrupt the state of the object. Accessor Consequently, accessor methods must consequently return defensive copies of internal mutable objects ; (see rule OBJ05-J. Defensively copy private mutable class members before returning their references for additional information).

Noncompliant Code Example

This noncompliant code example contains a TOCTOU inconsistencyvulnerability. Because cookie is a mutable input, an attacker can cause the cookie to expire between the initial check (the hasExpired() call) and the actual use (the doLogic() call).

...

Code Block
bgColor#ccccff
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 whether cookie has expired
    if (cookie.hasExpired()) {
      // Cookie is no longer valid, handle condition by throwing an exception
    }

    doLogic(cookie);
  }
}

Compliant Solution

You must make defensive copies of all mutable inputs to comply with this rule. Some copy constructors and clone() methods perform a shallow copy of the original instance. For example, invocation of clone() on an array results in creation of an array instance whose elements have the same values as the original instance. 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 performs element duplication when the input consists of mutable components, such as an array of cookies. In this case, a deep copy must be performed that also duplicates the reference elements.

This compliant solution demonstrates correct use both of a shallow copy (for the array of int) and also of a deep copy (for the array of cookies).

...

When the class of a mutable input is non-final, or is an interface, an attacker can write a subclass that maliciously overrides the parent class's clone() method. The attacker's clone() method could then can subsequently subvert defensive copying. This noncompliant code example demonstrates the this weakness.

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

...

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. Note, 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 still be defensively copied before use. For the case of the java.lang.CharacterSequence interface, one permissible approach is to obtain an immutable copy of the characters by using the toString() method. 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.

...

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

...

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="7346b7383c3c93f3-a77869b3-4ad843ea-8473b65a-2610fe983b883e4feb7aaaac"><ac:plain-text-body><![CDATA[

[[Bloch 2008

AA. Bibliography#Bloch 08]]

Item 39: Make defensive copies when needed

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="895fe1307a8cbb05-ff7a46d8-48c547bf-8e60b18f-1378e4f81ecfd57bc075d910"><ac:plain-text-body><![CDATA[

[[Pugh 2009

AA. Bibliography#Pugh 09]]

Returning references to internal mutable state

]]></ac:plain-text-body></ac:structured-macro>

...