- SSI Injection Vulnerability
- SSI Injection Attack Scenario
- Mitigations of SSI Injection Vulnerability
- How Briskinfosec helps you?
- Curious to read our case study?
- Last but not the least
- You may be interested on
Server Side Includes (SSIs) are directives present on web applications, used to feed an HTML page of the application with dynamic contents based on user’s input. It is a feature that allows developers to dynamically generate web content (html) by using ‘#’ directives. SSI directives are similar to Common Gateway interfaces (CGIs), except that, SSIs are used to execute some actions before the current page is loaded. In order to do that, web server or the application, search for SSI directives in the HTML code and executes them before supplying the page to the end user.
SSI Injection Vulnerability:
Server Side Includes Injection vulnerability allows an attacker to exploit a web application by injecting scripts or SSI directives in HTML pages. SSI injection attack is done by manipulation of SSI used in the application through user inputs.
In order to detect SSI injection vulnerability, we can check whether the application is sanitizing html or SSI directive inputs as shown below:
Another way to detect if the application is vulnerable to SSI Injection is by searching for the presence of web pages with extensions like .stm, .shtm, and .shtml. Sometimes, applications are vulnerable even if there are no web pages with above extensions.
SSI injection may lead to file system access with the privileges of web server. Attackers can access sensitive files, execute shell commands with server privileges, etc.
SSI Injection Attack Scenario:
For SSI injection attack demonstration, I’ll be using bWAPP, a vulnerable web application for practice purposes.
- I have set up bWAPP in my local XAMPP server. After that, I’ve opened the SSI injection page of bWAPP application.
- In bWAPP SSI page, the application is asking for user’s first and last name inputs. When the user gives the inputs, it uses SSI directives in the server to fetch the IP address of the specific user name that we’ve given to the application.
- Below image shows the backend PHP code for the above SSI injection page. In the source code, we can see that the developer is dynamically generating the web content (User’s IP address in our example) by using a SSI directive which fetches the IP address of the given user.
- Now to exploit this, we can inject a SSI directive payload with /etc/passwd to fetch the contents of passwd file in the backend web server. This can be done by using the below payload:
- After injecting the above payload in either first or last name input, application exposes the passwd file contents in response page as shown below:
- In the same manner, attacker can craft different payloads with SSI directives and can execute arbitrary commands on the vulnerable server. The same SSI injection can be performed in HTTP request headers also. I’ve listed some of the SSI Injection payloads for reader’s reference below:
SSI Payload List:
Mitigations of SSI Injection Vulnerability:
- User Inputs should be validated properly in both client side and server side.
- HTML and SSI Directive inputs like < > ! # should be sanitized securely by using server -side sanitization functions like the htmlentities of PHP.
SSI injection is a rare vulnerability, but if exploited, gives a system level access to the intruder. Attacker can manipulate the file system and run system commands using SSI injection exploitation. Since it’s a rare vulnerability, there is a high probability that developers might not be aware of this and while using a SSI directive, developers might not properly sanitize the user inputs. Hence, Briskinfosec recommends to conduct application security assessment for public as well as to corporate internal applications to avoid such vulnerabilities which poses a serious threat for an organization’s reputation.
How Briskinfosec helps you?
Briskinfosec provides proper website/application security assessment and assesses your security environment. During the assessment, we completely validate the user inputs in the URL and hunt for figuring out strange ones. Once identified, we eliminate it with our experienced security folks and make mightier, your security defenses.
Curious to read our case study?
Our stakeholder, one of the unique HR solution providers, wanted us to perform an effective security assessment on their web applications. While doing security assessment on their entire web applications, we were able to identify many vulnerabilities including CRLF, then eliminated them, and strengthened their security environment. Check out our case study to know it fully.
Last but not the least:
Haven’t you read our Threatsploit Adversary report. If so, read it out. It’s a single report that contains the collection of worldwide happened cyber breaches, the reasons for those to surge, the repercussions organizations had to undergo, the remediations for those, and much more sane things. Click it and you’ll feel blessed to have got the most time-consuming ones, in just a fraction of second.
You may be interested on:
CWE-78-Improper Neutralization Of Special Elements Used In An OS Command Injection
CWE-79-Improper Neutralization Of Input During Web Page Generation Cross Site Scripting
Drupal Core Remote Code Execution Vulnerability:-CVE-2019-6340