| Attack Pattern ID | Pattern Abstraction: Standard 101 |
| Typical Severity | High |
| Description | 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. Attack Execution Flow Explore Determine applicability: The attacker determines whether server side includes are enabled on the target web server. |
Attack Step Techniques |
|---|
| Description | Environments |
|---|
| 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. | env-Web | | 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. | env-Web |
|
Indicators of Susceptibility
|
|---|
| ID | Type | Description | Environments |
|---|
| c101s1i1 | Positive | If .htaccess files are used, their contents should be checked for "Options Includes" or "Options IncludesNOEXEC". | env-Web | | c101s1i2 | Positive | If apache is used, the contents of the httpd.conf file and similar configuration files should be checked for "Options Includes" or "Options IncludesNOEXEC". | env-Web | | c101s1i3 | Positive | IIS configurations contain server-side include compatibility. | env-Web | | c101s1i4 | Inconclusive | Web pages that include mundane, but dynamic information (like the current date, a file's size, or some other data that SSI can produce) might be producing that content through SSI. | env-Web |
|
Security Control |
|---|
| ID | Type | Description |
|---|
| c101s1s1 | Preventative | Adding "AllowOverrides none" to the main httpd.conf file on an server (and the similar restrictions in other application servers) can prevent unexpected loosening of SSI functionality, even by internal developers. |
Attempt SSI: Look for user controllable input, including HTTP headers, that can carry server side include directives to the web server |
Attack Step Techniques |
|---|
| Description | Environments |
|---|
| Use a spidering tool to follow and record all links. Make special note of any links that include parameters in the URL. | env-Web | | 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. | env-Web |
|
Indicators of Susceptibility
|
|---|
| ID | Type | Description | Environments |
|---|
| c101s2i1 | Positive | URL parameters are used. | env-Web | | c101s2i2 | Inconclusive | No parameters appear on the URL. Even though none appear, the web application may still use them if they are provided. | env-Web |
|
Outcome |
|---|
| ID | Type | Description |
|---|
| c101s2o1 | Success | A list of URLs, with their corresponding parameters is created by the attacker. |
|
Security Controls |
|---|
| ID | Type | Description |
|---|
| c101s2s1 | Detective | Monitor velocity of page fetching in web logs. Humans who view a page and select a link from it will click far slower and far less regularly than tools. Tools make requests very quickly and the requests are typically spaced apart regularly (e.g. 0.8 seconds between them). | | c101s2s2 | Detective | Create links on some pages that are visually hidden from web browsers. Using IFRAMES, images, or other HTML techniques, the links can be hidden from web browsing humans, but visible to spiders and programs. A request for the page, then, becomes a good predictor of an automated tool probing the application. | | c101s2s3 | Preventative | Actively monitor the application and either deny or redirect requests from origins that appear to be automated. |
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 |
Outcomes |
|---|
| ID | Type | Description |
|---|
| c101s3o1 | Success | The attacker views data (perhaps from a file) that he normally should not see. | | c101s3o2 | Success | The attacker executes a command on the server, or influences the arguments to a command executed via SSI on the server. |
|
| Attack 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 |
| Typical Likelihood of Exploit |
Very High
It is fairly easy to determine whether server-side includes are permitted on the target server. An attacker can potentially glean a lot of information if SSI Injection were found to be possible.
|
| Methods of Attack | - Injection
- Protocol Manipulation
|
| Examples-Instances | Description Consider a website hosted on a server that permits Server Side Includes (SSI), such as Apache with the "Options Includes" directive enabled.
Whenever an error occurs, the HTTP Headers along with the entire request are logged, which can then be displayed on a page that allows review of such errors. A malicious user can inject SSI directives in the HTTP Headers of a request designed to create an error.
When these logs are eventually reviewed, the server parses the SSI directives and executes them.
|
| Attacker Skill or Knowledge Required | Medium: The attacker needs to be aware of SSI technology, determine the nature of injection and be able to craft input that results in the SSI directives being executed. |
| Resources Required | None: Determining whether the server supports SSI does not require special tools, and nor does injecting directives that get executed. |
| Probing Techniques | The attacker can probe for enabled SSI by injecting content that can be interpreted as SSI directives and viewing the page output |
| Solutions and Mitigations | 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 |
| Attack Motivation-Consequences | - Information Leakage
- Run Arbitrary Code
|
| Context Description | Server Side Include is a technology that allows having the server parse some code before rendering an HTML page, without having to take recourse in a full-fledged server side language.
This technology is usually used to display items such as "Last-Modified Date" or the current date and time on the server, and include other pieces of code, such as the output from a shell command or another html file. The latter is used to display things such as a common footer on HTML pages.
A special file extension, usually .shtml, is used for server-parsed documents. The date is then displayed as <!--#echo var="DATE_LOCAL" --> and a footer file, footer.html is included as <!--#include virtual="/footer.html" -->
However, for web sites that allow user-submitted content to be displayed on its pages, this is a potential minefield, since the user can easily insert the statement <!--#include virtual="/etc/passwd" --> to insert, and subsequently, view the password file on the machine.
The problems that cause SSI Injection are the same as those that cause Cross Site Scripting - lack of input validation and sanitization of the output. If content is appropriately encoded before being rendered, the server would not interpret it as SSI tags and would, therefore, not execute it.
|
| Injection Vector | User controllable input |
| Payload | SSI directives that can cause disclosure of file contents or execution of commands |
| Activation Zone | The web server that parses and executes SSI directives before rendering the HTML page |
| Payload Activation Impact | The SSI directives cause the inclusion of certain file's contents or the execution of a shell command, as directed by the attacker |
| Related Weaknesses | | CWE-ID | Weakness Name | Weakness Relationship Type |
|---|
| 97 | Failure to Sanitize Server-Side Includes (SSI) Within a Web Page | Targeted | | 74 | Failure to Sanitize Data into a Different Plane (aka 'Injection') | Secondary | | 20 | Insufficient Input Validation | Secondary |
|
| Related Security Principles | - Reluctance To Trust
- Complete Mediation
|
| Related Guidelines | - Never Use Unvalidated Input as Part of a Directive to any Internal Component
|
| Purpose | Penetration Exploitation |
| CIA Impact | | Confidentiality Impact | Integrity Impact | Availability Impact |
|---|
| High | High | High |
|
| Technical Context | | Architectural Paradigm | Framework | Platform | Language |
|---|
| Client-Server | All | All | All |
|
| Source | | Submission(s) |
|---|
| Submitter | Organization | Date | Comment |
|---|
| Chiradeep B. Chhaya | | 2007-04-20 | First Draft |
| Modification(s) |
|---|
| Modifier | Organization | Date | Comment |
|---|
| Sean Barnum | Cigital, Inc | 2007-04-20 | Review and revision of content |
|
