SEC09-J. Do not base security checks on untrusted sources

Security checks based on untrusted sources can be bypassed. The untrusted object or parameter should be defensively copied before the security check is performed. The copy operation must be a deep copy; the implementation of the clone() method may produce a shallow copy, which can still be compromised. In addition, the implementation of the clone() method can be provided by the attacker. See guidelines VOID MET08-J. Do not use the clone method to copy untrusted method parameters and OBJ14-J. Defensively copy mutable inputs and mutable internal components for more information.

Noncompliant Code Example

This noncompliant code example describes a security vulnerability from the JDK 5.0 java.io package. In this release, java.io.File was non-final, allowing an attacker to supply an untrusted parameter constructed by extending the legitimate java.io.File class. In this manner, the getPath() method can be overridden so that the security check passes the first time it is called but the value changes the second time to refer to a sensitive file such as /etc/passwd. This is a time-of-check-time-of-use (TOCTOU) vulnerability.

public RandomAccessFile openFile(final java.io.File f) {
  askUserPermission(f.getPath());
  // ...
  return (RandomAccessFile)AccessController.doPrivileged() {
    public Object run() {
      return new RandomAccessFile(f.getPath());
    }
  }
}

The attacker can extend java.io.File as follows:

public class BadFile extends java.io.File {
  private int count;
  public String getPath() {
    return (++count == 1) ? "/tmp/foo" : "/etc/passwd";
  }
}

Compliant Solution

This compliant solution ensures that the java.io.File object can be trusted. First, its reference is declared to be final preventing an attacker from modifying the reference to substitute a different object. Second, the solution creates a new java.io.File object using the standard java.io.File constructor. This ensures that any methods invoked on the File object are the standard library methods rather than overriding methods potentially provided by the attacker.

public RandomAccessFile openFile(java.io.File f) {
  final java.io.File copy = new java.io.File(f.getPath());
  askUserPermission(copy.getPath());
  // ...
  return (RandomAccessFile)AccessController.doPrivileged() {
    public Object run() {
      return new RandomAccessFile(copy.getPath());
    }
  }
}

Note that using the clone() method instead of the openFile() method would copy the attacker's class, which is not desirable. (Refer to guideline VOID MET08-J. Do not use the clone method to copy untrusted method parameters.)

Risk Assessment

Basing security checks on untrusted sources can result in the check being bypassed.

Automated Detection

TODO

Related Vulnerabilities

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

Related Guidelines

MITRE CWE: CWE-302 "Authentication Bypass by Assumed-Immutable Data"

Bibliography

[[Sterbenz 2006]]

SEC08-J. Protect sensitive operations with security manager checks      14. Platform Security (SEC)      SEC10-J. Define custom security permissions for fine grained security