Page History

Do not operate on unvalidated or untrusted data (also known as tainted data) in a doPrivileged() block. An attacker can supply malicious input that could result in privilege escalation attacks. Appropriate mitigations include hard coding values rather than accepting arguments (when appropriate) , and validating or validating/ sanitizing data before the privileged operations .This rule concerns untrusted information entering a doPrivileged() block. For prevention of sensitive information escaping from a doPrivileged () block, see SEC00IDS00-J. Do not allow doPrivileged() blocks to leak sensitive information outside Sanitize untrusted data passed across a trust boundary).

Noncompliant Code Example

This noncompliant code example accepts a tainted filename path or file name as an argument. An attacker can supply the path name of a sensitive password file, consequently allowing an unprivileged user to access a protected fileaccess a protected file by supplying it's pathname as an argument to this method.

private void privilegedMethod(final String filename) throws FileNotFoundException {
  try {
    FileInputStream fis = (FileInputStream) AccessController.doPrivileged(
      new PrivilegedExceptionAction() {
        public FileInputStream run() throws FileNotFoundException {
          return new FileInputStream(filename);
        }
      }
    );
    // do something with the file and then close it
  } catch (PrivilegedActionException e) {
    // forward to handler and log
  }
}

...

This compliant solution invokes a sanitization method (cleanAFilenameAndPath) that can distinguish acceptable inputs from the cleanAFilenameAndPath()) sanitization method to disallow malicious inputs. Successful operation of the sanitization method indicates that the input is acceptable, and the doPrivileged block can be executed.

...

One potential drawback of this approach is that effective sanitization methods can be difficult to write. A benefit of this approach is that it works well in combination with taint analysis (see the Automated Detection , belowsection for this rule). For more information on how to securely validate and sanitize a file, perform secure file operations see FIO00-J. Do not operate on files in shared directories.

...

Sanitization of tainted inputs always carries the risk that the data is not fully sanitized. Both file and path name equivalence and directory traversal are common examples of vulnerabilities arising from the improper sanitization of path and file name inputs (see IDS02-J. Canonicalize path names before validating them). A design that requires an unprivileged user to access an arbitrary, protected file (or other resource) is always suspect. Consider alternatives such as using a hardcodeed hard coded resource name or permitting the user to select only from a list of options that are indirectly mapped to the resource names.

This compliant solution both explicitly hardcodes hard codes the name of the file and also confines the variables used in the privileged block to the same method. This ensures that no malicious file can be loaded by exploiting the privileges of the corresponding codeprivileged method.

static final String FILEPATH = "/path/to/protected/file/fn.ext";

private void privilegedMethod() throws FileNotFoundException {
 
  try {
    FileInputStream fis = (FileInputStream) AccessController.doPrivileged(
      new PrivilegedExceptionAction() {
        public FileInputStream run() throws FileNotFoundException {
          return new FileInputStream(FILEPATH);
        }
      }
    );
    // do something with the file and then close it
  } catch (PrivilegedActionException e) {
    // forward to handler and log
  }
}

...

Tools that support taint analysis enable assurance of code usage that is substantially similar to the first compliant solution. Typical taint analyses assume that a method or methods exist(s) that can "clean" cleanse potentially tainted inputs, providing untainted outputs (or appropriate errors). The taint analysis then ensures that only untainted data is used inside the doPrivileged block. Note that the static analyses must necessarily assume that the cleaning cleansing methods are always successful; in reality this may not be the case.

...

...