...
This noncompliant code example contains a TOCTOU vulnerability. Because cookie
is a mutable input, an attacker can cause it to expire between the initial check (the hasExpired()
call) and the actual use (the doLogic()
call).
Code Block | ||
---|---|---|
| ||
public final class MutableDemo {
// java.net.HttpCookie is mutable
public void useMutableInput(HttpCookie cookie) {
if (cookie == null) {
throw new NullPointerException();
}
// Check whether 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);
}
}
|
...
This compliant solution avoids the TOCTOU vulnerability by copying the mutable input and performing all operations on the copy. Consequently, an attacker's changes to the mutable input cannot affect the copy. Acceptable techniques include using a copy constructor or implementing the java.lang.Cloneable
interface and declaring a public clone method (for classes not declared final). In cases like HttpCookie
where the mutable class is declared final — that is, it cannot provide an accessible copy method — perform a manual copy of the object state within the caller. See rule OBJ04-J. Provide mutable classes with copy functionality to safely allow passing instances to untrusted code for more information. Note that any input validation must be performed on the copy rather than on the original object.
Code Block | ||
---|---|---|
| ||
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);
}
}
|
...
This compliant solution demonstrates correct use both of a shallow copy (for the array of int
) and of a deep copy (for the array of cookies).
Code Block | ||
---|---|---|
| ||
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);
}
|
...
When the class of a mutable input is nonfinal or is an interface an attacker can write a subclass that maliciously overrides the parent class's clone()
method. The attacker's clone()
method can subsequently subvert defensive copying. This noncompliant code example demonstrates this weakness.
Code Block | ||
---|---|---|
| ||
// java.util.Collection is an interface
public void copyInterfaceInput(Collection<String> collection) {
doLogic(collection.clone());
}
|
...
This compliant solution protects against potential malicious overriding by creating a new instance of the nonfinal mutable input, using the expected class rather than the class of the potentially malicious argument. The newly created instance can be forwarded to any code capable of modifying it.
Code Block | ||
---|---|---|
| ||
public void copyInterfaceInput(Collection<String> collection) {
// Convert input to trusted implementation
collection = new ArrayList(collection);
doLogic(collection);
}
|
...
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
OBJ06-J | medium | probable | high | P4 | L3 |
Related Vulnerabilities
CVE-2012-0507 describes an exploit that managed to bypass Java's applet security sandbox and run malicious code on a remote user's machine. The exploit created a data structure that is normally impossible to create in Java, but was built using deserialization, and the deserialization process did not perform defensive copies of the deserialized data. See the code examples in SER07-J. Do not use the default serialized form for classes with implementation-defined invariants for more information.
Related Guidelines
Secure Coding Guidelines for the Java Programming Language, Version 3.0 | Guideline 2-2. Create copies of mutable outputs |
...
Item 39. Make defensive copies when needed | |
Returning References to Internal Mutable State |
OBJ05-J. Defensively copy private mutable class members before returning their references 04. Object Orientation (OBJ)