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 "Argument Injection or Modification"
(→Categories) |
(adjustments to new template) |
||
Line 1: | Line 1: | ||
{{Template:Attack}} | {{Template:Attack}} | ||
+ | |||
+ | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | ||
==Description== | ==Description== | ||
+ | |||
Argument Injection or Modification is a specific case of attack, which belongs to Injection attacks familly. Modifying or injecting data as arguments the attacker may lead to very simmilar, often the same results as in other injection attacks. It plays no difference if the attacker wants to inject the system command into argument or into any other part of the code. | Argument Injection or Modification is a specific case of attack, which belongs to Injection attacks familly. Modifying or injecting data as arguments the attacker may lead to very simmilar, often the same results as in other injection attacks. It plays no difference if the attacker wants to inject the system command into argument or into any other part of the code. | ||
+ | |||
+ | |||
+ | ==Risk Factors== | ||
+ | |||
+ | |||
==Examples == | ==Examples == | ||
− | + | ===Example 1=== | |
− | |||
Knowing pseudo code of the application the attacker may guess, what action is required by the application to perform another one. E.g. what must be done to authorize the attacker as the administrator. | Knowing pseudo code of the application the attacker may guess, what action is required by the application to perform another one. E.g. what must be done to authorize the attacker as the administrator. | ||
Line 27: | Line 34: | ||
− | + | ===Example 2=== | |
If security mechanism doesn't protect data as it should, e.g. doesn't check the identity of the user and private data are displayed to him despite of fact they shouldn't, then such user may try to alter arguments and get access to data owned by a different user. | If security mechanism doesn't protect data as it should, e.g. doesn't check the identity of the user and private data are displayed to him despite of fact they shouldn't, then such user may try to alter arguments and get access to data owned by a different user. | ||
Line 34: | Line 41: | ||
− | ==Related | + | ==Related [[Threat Agents]]== |
+ | |||
+ | * [[Category:Command Execution]] | ||
+ | |||
+ | |||
+ | ==Related [[Attacks]]== | ||
+ | |||
+ | * [[Command Injection]] | ||
+ | * [[Code Injection]] | ||
+ | * [[SQL Injection]] | ||
+ | * [[LDAP Injection]] | ||
+ | * [[SSI Injection]] | ||
+ | * [[XSS]] | ||
+ | |||
+ | |||
+ | ==Related [[Vulnerabilities]]== | ||
− | [[Category: | + | * [[Category:Input Validation Vulnerability]] |
− | |||
− | + | ==Related [[Controls]]== | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | * validation of the format / expected classes of charachetrs / input/output data size | |
− | |||
− | == | + | ==References== |
− | |||
− | |||
[[Category: Injection]] | [[Category: Injection]] | ||
− |
Revision as of 15:50, 15 June 2008
- This is an Attack. To view all attacks, please see the Attack Category page.
Last revision (mm/dd/yy): 06/15/2008
Description
Argument Injection or Modification is a specific case of attack, which belongs to Injection attacks familly. Modifying or injecting data as arguments the attacker may lead to very simmilar, often the same results as in other injection attacks. It plays no difference if the attacker wants to inject the system command into argument or into any other part of the code.
Risk Factors
Examples
Example 1
Knowing pseudo code of the application the attacker may guess, what action is required by the application to perform another one. E.g. what must be done to authorize the attacker as the administrator.
Reading the code below the attacker doesn't know the values of $pass and $login. The question is - is there possiblity of altering value of $authorized not knowing previously mentioned variables?
$authorized=0; if($pass = "XXX" and $login = "XXX") { $authorized = 1; } if($authorized == 1) { admin_panel(); }
If server configuration allows for that, we may try to pass argument $authorized=1 as input data to application.
E.g. /index.php?user=&pass=&authorized=1
Example 2
If security mechanism doesn't protect data as it should, e.g. doesn't check the identity of the user and private data are displayed to him despite of fact they shouldn't, then such user may try to alter arguments and get access to data owned by a different user.
E.g. By entering address http://testsite.com/index.php?invoice=12 user is able to check one of his invoices. Modifying "invoice" argument, considering above assumptions, the attacker may try to access other user's invoices. Usefull to the attacker in this example would be performing a brute-force attack.
Related Threat Agents
Related Attacks
Related Vulnerabilities
Related Controls
- validation of the format / expected classes of charachetrs / input/output data size