Page History

If security Security checks are based on untrusted sources , it becomes possible to bypass them. It is recommended to defensively copy the can be bypassed. Any untrusted object or parameter before the argument must be defensively copied before a security check is carried out. For this purpose deep copies must be created as opposed to using performed. The copy operation must be a deep copy; the implementation of the clone() method to create shallow copies. See guidelines MET08-J. Do not use the clone method to copy untrusted method parameters and FIO00may produce a shallow copy, which can still be compromised. In addition, the implementation of the clone() method can be provided by the attacker (see OBJ06-J. Defensively copy mutable inputs and mutable internal components for more information).

Noncompliant Code Example

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

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

The attacker can could 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

...

(Final)

This vulnerability can be mitigated by declaring java.io.File final.

Compliant Solution (Copy)

Security checks should not be based on untrusted sources. This compliant solution ensures that the java.io.File object cannot be untrusted. This is achieved by declaring java.io.File as final and ensuring that a new java.io.File object is created in the openFile() method. Note that using the clone() method instead of the openFile() method would copy the attacker's class, which is not desirable. (Refer to guideline MET08-J. Do not use the clone method to copy untrusted method parameters.)can be trusted despite not being final. The solution creates a new File object using the standard constructor. This technique ensures that any methods invoked on the File object are the standard library methods and not overriding methods that have been 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(new PrivilegedAction <Object>() {
    public Object run() {
      return new RandomAccessFile(copy, copy.getPath());
    }
  });
}

Note that using the clone() method instead of the openFile() method would copy the attacker's class, which is not desirable (see OBJ06-J. Defensively copy mutable inputs and mutable internal components).

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 rule on the CERT website.

References

\[[Sterbenz 2006|AA. Java References#Sterbenz 06]\] 
\[[MITRE 2009|AA. Java References#MITRE 09]\] [CWE ID 302|http://cwe.mitre.org/data/definitions/302.html] "Authentication Bypass by Assumed-Immutable Data"

Tool	Version	Checker	Description
Coverity	7.5	UNSAFE_REFLECTION	Implemented
Parasoft Jtest	Include Page Parasoft_V Parasoft_V	CERT.SEC02.TDRFL	Protect against Reflection injection

Related Guidelines

Android Implementation Details

The code examples using the java.security package are not applicable to Android, but the principle of the rule is applicable to Android apps.

Bibliography

...

Image Added Image Added Image AddedSEC08-J. Enforce security checks in code that performs sensitive operations      02. Platform Security (SEC)      SEC10-J. Define custom security permissions for fine grained security