Difference between revisions of "Argument Injection or Modification"

From OWASP
Jump to: navigation, search
(Related Threat Agents)
(Reverting to last version not containing links to www.textdronacelliba.com)
(8 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
<br>
 
<br>
 
[[Category:OWASP ASDR Project]]
 
[[Category:OWASP ASDR Project]]
[[ASDR Table of Contents]]__TOC__
 
  
  
Line 13: Line 12:
 
==Risk Factors==
 
==Risk Factors==
 
TBD
 
TBD
[[Category:FIXME|add content here]]
 
  
 
==Examples ==
 
==Examples ==
Line 43: Line 41:
  
 
==Related [[Threat Agents]]==
 
==Related [[Threat Agents]]==
 
 
TBD
 
TBD
[[Category:FIXME|need links]]
 
  
 
==Related [[Attacks]]==
 
==Related [[Attacks]]==
 
 
* [[Command Injection]]
 
* [[Command Injection]]
 
* [[Code Injection]]
 
* [[Code Injection]]
Line 54: Line 49:
 
* [[LDAP injection]]
 
* [[LDAP injection]]
 
* [[Server-Side_Includes_%28SSI%29_Injection|Sever-Side Includes (SSI) Injection]]
 
* [[Server-Side_Includes_%28SSI%29_Injection|Sever-Side Includes (SSI) Injection]]
* [[Cross-site scripting]]
+
* [[Cross-site Scripting (XSS)]]
  
 
==Related [[Vulnerabilities]]==
 
==Related [[Vulnerabilities]]==
 
 
* [[:Category:Input Validation Vulnerability]]
 
* [[:Category:Input Validation Vulnerability]]
 
  
 
==Related [[Controls]]==
 
==Related [[Controls]]==
 
 
* [[Input Validation]]
 
* [[Input Validation]]
 +
* [[Output Validation]]
 +
* [[Canonicalization]]
  
 
==References==
 
==References==
 
TBD
 
TBD
[[Category:FIXME|add references here]]
 
  
  
 
[[Category: Injection]]
 
[[Category: Injection]]
 
[[Category: Attack]]
 
[[Category: Attack]]

Revision as of 13:29, 27 May 2009

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




Last revision (mm/dd/yy): 05/27/2009

Description

Argument Injection or Modification is a type of Injection attack. Modifying or injecting data as an argument may lead to very similar, often the same, results as in other injection attacks. It makes no difference if the attacker wants to inject the system command into arguments or into any other part of the code.

Risk Factors

TBD

Examples

Example 1

Knowing pseudo code of the application, the attacker may guess what action is required by the application to perform another one, for example, 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 the security mechanism doesn't protect data as it should, e.g. doesn't check the identity of the user, and private data are displayed (despite that they shouldn't), then the user may try to alter arguments and get access to data owned by a different user.

For example, by entering the address http://testsite.com/index.php?invoice=12 a user is able to check one of his invoices. Modifying the "invoice" argument, considering the above assumptions, the attacker may try to access other user's invoices. This might be useful to the attacker in a Brute force attack.

Related Threat Agents

TBD

Related Attacks

Related Vulnerabilities

Related Controls

References

TBD