Name: Untrusted input for a condition


Using untrusted inputs in a statement that makes a security decision makes code vulnerable to attack.

ID: cpp/tainted-permissions-check

Kind: problem

Severity: warning

Precision: medium

 * @name Untrusted input for a condition
 * @description Using untrusted inputs in a statement that makes a
 *              security decision makes code vulnerable to
 *              attack.
 * @kind problem
 * @problem.severity warning
 * @precision medium
 * @id cpp/tainted-permissions-check
 * @tags security
 *       external/cwe/cwe-807


 * Holds if there is an 'if' statement whose condition `condition`
 * is influenced by tainted data `source`, and the body contains
 * `raise` which escalates privilege.
predicate cwe807violation(Expr source, Expr condition, Expr raise) {
  tainted(source, condition) and
  raisesPrivilege(raise) and
  exists(IfStmt ifstmt |
    ifstmt.getCondition() = condition and
    raise.getEnclosingStmt().getParentStmt*() = ifstmt

from Expr source, Expr condition, Expr raise
where cwe807violation(source, condition, raise)
select condition, "Reliance on untrusted input $@ to raise privilege at $@", source,
  source.toString(), raise, raise.toString()

This rule finds code where untrusted inputs are used in an if statement, and the body of that statement makes a security decision. This is an example of CWE-807 and makes the program vulnerable to attack. An attacker might be able to gain unauthorized access to the system by manipulating external inputs to the system.


In most cases, you need to add or strengthen the checks made on the user-supplied data to ensure its integrity. The user-supplied data can then be used as a trusted input to the security decision. For example, instead of checking an HTTP cookie against a predictable fixed string, check a cookie against a randomly generated session key.

This rule may highlight a few conditions where user-supplied data has been checked and can be trusted. It is not always possible to determine if the checks applied to data are enough to ensure security.


The following example is included in CWE 807.

     1struct hostent *hp;struct in_addr myaddr;
     2char* tHost = "";
     5hp = gethostbyaddr((char *) &myaddr, sizeof(struct in_addr), AF_INET);
     6if (hp && !strncmp(hp->h_name, tHost, sizeof(tHost))) {
     7  trusted = true;
     8} else {
     9  trusted = false;
struct hostent *hp;struct in_addr myaddr;
char* tHost = "";

hp = gethostbyaddr((char *) &myaddr, sizeof(struct in_addr), AF_INET);
if (hp && !strncmp(hp->h_name, tHost, sizeof(tHost))) {
  trusted = true;
} else {
  trusted = false;

In this example, the result of a reverse DNS query is compared against a fixed string. An attacker can return an incorrect reverse DNS entry for the requesting IP and thus gain the same access as a legitimate user from

To fix the problem in this example, you need to add an additional mechanism to test the user-supplied data. For example, numeric IP addresses could be used.