This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.

How does a Manipulating User-Controlled Variables attack work?

It typically unfolds over 3 phases. It begins with: [Probe target application] The adversary first probes the target application to determine important information about the target. This information could include types software used, software versions, what user input the application consumes, and so on.

How do you prevent CAPEC-77?

Do not allow override of global variables and do Not Trust Global Variables. If the register_globals option is enabled, PHP will create global variables for each GET, POST, and cookie variable included in the HTTP request. This means that a malicious user may be able to set variables unexpectedly. For instance make sure that the server setting for PHP does not expose global variables.

What weaknesses does CAPEC-77 target?

CAPEC-77 exploits 7 CWE weaknesses, including CWE-15 (External Control of System or Configuration Setting), CWE-94 (Improper Control of Generation of Code ('Code Injection')), CWE-96 (Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')), CWE-285 (Improper Authorization).

How severe is CAPEC-77?

MITRE rates CAPEC-77 as Very High severity with high likelihood of attack.

CAPEC-77: Manipulating User-Controlled Variables

Examples

PHP is a study in bad security. The main idea pervading PHP is "ease of use," and the mantra "don't make the developer go to any extra work to get stuff done" applies in all cases. This is accomplished in PHP by removing formalism from the language, allowing declaration of variables on first use, initializing everything with preset values, and taking every meaningful variable from a transaction and making it available. In cases of collision with something more technical, the simple almost always dominates in PHP. One consequence of all this is that PHP allows users of a Web application to override environment variables with user-supplied, untrusted query variables. Thus, critical values such as the CWD and the search path can be overwritten and directly controlled by a remote anonymous user. Another similar consequence is that variables can be directly controlled and assigned from the user-controlled values supplied in GET and POST request fields. So seemingly normal code like this, does bizarre things: while($count < 10){ // Do something $count++; } Normally, this loop will execute its body ten times. The first iteration will be an undefined zero, and further trips though the loop will result in an increment of the variable $count. The problem is that the coder does not initialize the variable to zero before entering the loop. This is fine because PHP initializes the variable on declaration. The result is code that seems to function, regardless of badness. The problem is that a user of the Web application can supply a request such as GET /login.php?count=9 and cause $count to start out at the value 9, resulting in only one trip through the loop. Yerg. Depending on the configuration, PHP may accept user-supplied variables in place of environment variables. PHP initializes global variables for all process environment variables, such as $PATH and $HOSTNAME. These variables are of critical importance because they may be used in file or network operations. If an adversary can supply a new $PATH variable (such as PATH='/var'), the program may be exploitable. PHP may also take field tags supplied in GET/POST requests and transform them into global variables. This is the case with the $count variable we explored in our previous example. Consider another example of this problem in which a program defines a variable called $tempfile. An adversary can supply a new temp file such as $tempfile = "/etc/passwd". Then the temp file may get erased later via a call to unlink($tempfile);. Now the passwd file has been erased--a bad thing indeed on most OSs. Also consider that the use of include() and require() first search $PATH, and that using calls to the shell may execute crucial programs such as ls. In this way, ls may be "Trojaned" (the adversary can modify $PATH to cause a Trojan copy of ls to be loaded). This type of attack could also apply to loadable libraries if $LD_LIBRARY_PATH is modified. Finally, some versions of PHP may pass user data to syslog as a format string, thus exposing the application to a format string buffer overflow. See also: File upload allows arbitrary file read by setting hidden form variables to match internal variable names (CVE-2000-0860)

CAPEC-77: Manipulating User-Controlled Variables

Overview

How the attack works

What the attacker needs

Prerequisites

Skills required

Consequences

How to mitigate it

How to detect it

Examples

Frequently asked questions

References

Defend against CAPEC-77

Overview

How the attack works

What the attacker needs

Prerequisites

Skills required

Consequences

How to mitigate it

How to detect it

Examples

Related weaknesses

Related attack patterns

Parent

Child

Frequently asked questions

References

Defend against CAPEC-77