Name |
Server Side Include (SSI) Injection |
|
Likelyhood of attack |
Typical severity |
High |
High |
|
Summary |
An attacker can use Server Side Include (SSI) Injection to send code to a web application that then gets executed by the web server. Doing so enables the attacker to achieve similar results to Cross Site Scripting, viz., arbitrary code execution and information disclosure, albeit on a more limited scale, since the SSI directives are nowhere near as powerful as a full-fledged scripting language. Nonetheless, the attacker can conveniently gain access to sensitive files, such as password files, and execute shell commands. |
Prerequisites |
A web server that supports server side includes and has them enabled User controllable input that can carry include directives to the web server |
Execution Flow |
Step |
Phase |
Description |
Techniques |
1 |
Explore |
[Determine applicability] The attacker determines whether server side includes are enabled on the target web server. |
- Look for popular page file names. The attacker will look for .shtml, .shtm, .asp, .aspx, and other well-known strings in URLs to help determine whether SSI functionality is enabled.
- Fetch .htaccess file. In Apache web server installations, the .htaccess file may enable server side includes in specific locations. In those cases, the .htaccess file lives inside the directory where SSI is enabled, and is theoretically fetchable from the web server. Although most web servers deny fetching the .htaccess file, a misconfigured server will allow it. Thus, an attacker will frequently try it.
|
2 |
Explore |
[Attempt SSI] Look for user controllable input, including HTTP headers, that can carry server side include directives to the web server. |
- Use a spidering tool to follow and record all links. Make special note of any links that include parameters in the URL.
- Use a proxy tool to record all links visited during a manual traversal of the web application. Make special note of any links that include parameters in the URL. Manual traversal of this type is frequently necessary to identify forms that are GET method forms rather than POST forms.
|
3 |
Explore |
[Inject SSI] The attacker may then need to view a particular page in order to have the server execute the include directive and run a command or open a file on behalf of the attacker |
|
|
Solutions | Set the OPTIONS IncludesNOEXEC in the global access.conf file or local .htaccess (Apache) file to deny SSI execution in directories that do not need them All user controllable input must be appropriately sanitized before use in the application. This includes omitting, or encoding, certain characters or strings that have the potential of being interpreted as part of an SSI directive Server Side Includes must be enabled only if there is a strong business reason to do so. Every additional component enabled on the web server increases the attack surface as well as administrative overhead |
Related Weaknesses |
CWE ID
|
Description
|
CWE-20 |
Improper Input Validation |
CWE-74 |
Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') |
CWE-97 |
Improper Neutralization of Server-Side Includes (SSI) Within a Web Page |
CWE-713 |
OWASP Top Ten 2007 Category A2 - Injection Flaws |
|
Related CAPECS |
CAPEC ID
|
Description
|
CAPEC-253 |
The attacker forces an application to load arbitrary code files from a remote location. The attacker could use this to try to load old versions of library files that have known vulnerabilities, to load malicious files that the attacker placed on the remote machine, or to otherwise change the functionality of the targeted application in unexpected ways. |
|
Taxonomy: WASC |
Entry ID
|
Entry Name
|
36 |
SSI Injection |
|
Taxonomy: OWASP Attacks |
Entry ID
|
Entry Name
|
Link |
Server-Side Includes (SSI) Injection |
|