This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Difference between revisions of "Code Injection"

Jump to: navigation, search
Line 2: Line 2:
[[Category:OWASP ASDR Project]]
[[Category:OWASP ASDR Project]]
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

Revision as of 11:39, 23 April 2009

This is an Attack. To view all attacks, please see the Attack Category page.

Last revision (mm/dd/yy): 04/23/2009


Code Injection is the general name for a lot of types of attacks which depend on inserting code, which is interprated by the application. Such an attack may be be performed by adding strings of characters into a cookie or argument values in the URI. This attack makes use of lack of accurate input/output data validation, for example:

  • class of allowed characters (standard regular expressions classes or custom)
  • data format
  • amount of expected data
  • for numerical input, its values

Code Injection and Command Injection are measures used to achive simmilar goals. The concept of Code Injection is to add malicious code into an application, which then will be executed. Added code is a part of the application itself. It's not external code which is executed, like it would be in Command Injection.

Risk Factors



Example 1

If a site uses the include() fucntion, which operates on variables sent with the GET method, and there is no validation performed on them, then the attacker may try to execute different code than author of the code had in mind.

The URL below displays information about how to contact with the testsite company.

Below the altered code is code from The script "evilcode.php" may contain, for example, a phpinfo() function, which is useful for gaining information about the configuration of the environment in which the web service runs.

One condition must be satisfied for this example to be successful, namely the web server configuration must allow for including files in the "http://" notation.

Example 2

When a programmer uses the eval() function and operates on the data inside it, and these data may be altered by the attacker, then it's only one step closer to Code Injection.

The example below shows how to use the eval() function:

$myvar = "varname";
$x = $_GET['arg'];
eval("\$myvar = \$x;");

The code above which smells like a rose may be used to perform a Code Injection attack.

Example: passing in the URI /index.php?arg=1; phpinfo()

Exploiting bugs like these, the attacker doesn't have to limit himself only to a Code Injection attack. The attacker may tempt himself to use Command Injection technique, for example.

/index.pho?arg=1; system('id')

Related Threat Agents


Related Attacks

Related Vulnerabilities

Related Controls