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 "Direct Static Code Injection"
(→Example 1) |
(→Description) |
||
Line 10: | Line 10: | ||
Upon a user request to the modified resource, the actions defined in it will be executed at server side in the context of web server process. | Upon a user request to the modified resource, the actions defined in it will be executed at server side in the context of web server process. | ||
− | [[Server-Side Includes (SSI) Injection | Server Side Includes]] is considered a type of direct static code injection. It should not be confused with other types of code injection, like [[Cross-site | + | [[Server-Side Includes (SSI) Injection | Server Side Includes]] is considered a type of direct static code injection. It should not be confused with other types of code injection, like [[Cross-site Scripting (XSS)| XSS]] (“Cross-site scripting” or “HTML injection”) where the code is executed on the client side. |
==Risk Factors== | ==Risk Factors== |
Revision as of 12:48, 18 September 2008
- This is an Attack. To view all attacks, please see the Attack Category page.
ASDR Table of Contents
Last revision: 09/18/2008
Description
A Direct Static Code Injection attack consists of injecting code directly onto the resource used by application while processing a user request. This is normally performed by tampering libraries and template files which are created based on user input without proper data sanitization. Upon a user request to the modified resource, the actions defined in it will be executed at server side in the context of web server process.
Server Side Includes is considered a type of direct static code injection. It should not be confused with other types of code injection, like XSS (“Cross-site scripting” or “HTML injection”) where the code is executed on the client side.
Risk Factors
TBD
Examples
Example 1
This is a simple example of exploitation of a CGISCRIPT.NET csSearch 2.3 vulnerability, published on Bugtraq ID: 4368.
By requesting the following URL to the server, it’s possible to execute commands defined on the ‘’’’setup’’’ variable.
csSearch.cgi?command=savesetup&setup=PERL_CODE_HERE
For the classic example, the following command can be used to remove all files from “/” folder:
csSearch.cgi?command=savesetup&setup=`rm%20-rf%20/`
Note that the above command must be encoded in order to be accepted.
Example 2
This example exploits a vulnerability on Ultimate PHP Board (UPB) 1.9 (CVE-2003-0395), which allows an attacker to execute random php code. This happens because some user variables, like IP address and User-Agent, are stored in a file that is used by the admin_iplog.php page to show user statistics. When an administrator browses this page, the previously injected code by a malicious request is executed. The following example stores a malicious PHP code that will deface the index.html page when an administrator browses admin_iplog.php.
GET /board/index.php HTTP/1.0 User-Agent: <? system( "echo \'hacked\' > ../index.html" ); ?>