i Server side include injection(SSI) – All things in moderation

# Server side include injection(SSI)

Source : owasp

• Server-Side Includes(SSI) : is a simple interpreted server-side scripting language used almost exclusively for the Web.

for more about SSI define : https://en.wikipedia.org/wiki/Server_Side_Includes

• A successfull exploitation of this vulnerability allows an attacker to inject code into HTML pages or even perform remote code execution.
• SSI are directives that the web server parsers before serving the page to the user.  They represent an alternative to writing CGI(common gateway interface)  programs or embedding code using server-side languages.
for more about CGI define: https://en.wikipedia.org/wiki/Common_Gateway_Interface
• Putting an SSI directive into a static HTML document is as easy as writing a piece of code like the following:
<!--#echo var="DATE_LOCAL" -->


to print out the current time.

<!--#include virtual="/cgi-bin/counter.pl" -->


to include the output of a CGI script.

<!--#include virtual="/footer.html" -->


to include the content of a file or list files in a directory.

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


to include the output of a system command.

Then, if the web server’s SSI support is enabled, the web server will parse these default configuration, usually, most web servers don’t allow the use of the exec directive to system commands.

• To enabled SSI following tut: https://localsecurityblog.wordpress.com/2016/06/28/enable-server-site-include-apache-server/
• Example with lab bWAPP :

server side include

result:

•  How to test:
• Black box testing:
• Gathering infor : discover which kind of web server is running on our target, using classic information gathering techniques.
•  We could guess if SSI are supported just by looking at the content of the target web site. If it contains .shtml files, then SSI are probably supported.
• The next step consists of determining 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.
• Once we have a list of potential injection points, we can check if the input is correctly validated and then find out where the provided input is stored. We need to make sure that we can inject characters used in SSI directives:
< ! # = / . " - > and [a-zA-Z0-9]


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

alert("XSS")
• The injection can be performed also in HTTP headers, if the web application is going to use that data to build a dynamically generated page:
GET / HTTP/1.0
Referer: <!--#exec cmd="/bin/ps ax"-->
User-Agent: <!--#include virtual="/proc/version"-->

• 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.