With Server Side Injection, it’s possible for developers who may occasionally be required to create a static website due to business needs, to also insert some dynamic directives into static HTML pages to improve the functionality or aesthetics of the application. Because static web apps have fewer libraries and third-party components that can be exploited, maintaining their security is much simpler. Therefore, if firms use static websites rather than dynamic websites, they do not need to worry too much about cyber threats.
Server Side Injection, a server-based scripting language, is frequently used in web pages. The SSI standard is supported by the vast majority of web servers, including Litespeed, Apache, Ngnix, IIS, and others. Most frequently, SSI is used when a developer has to perform simple tasks to add a tiny amount of automation to a static website or to configure the environment variables for CGI, or computer-generated imagery. You must use an “include” directive if you want to include external files, run CGI scripts, or perform system activities before the current page loads or until after the page has been generated.
The web server evaluates the page as it loads on the server since the SSI is executed before the page loads or is visible to the user. With the use of several directives like include, execute, and others, SSI can load dynamic content like logos, headers, and other items. Each of these directives has a specific task and associated parameters that the attacker wishes to execute on the server. The fundamental directive syntax is:
Let’s talk about some of its instructions:
If a file needs to be referenced, only that file can be included here using the “include” directive, which will include the content of one directive into the other.
No matter what, the “exec” directive will run the command on the server whether Windows or Unix runs on the server. It also relies on the kind of value we pass in this place.
As an illustration, in this case, I’m supplying the value “whoami,” a Linux command that may be used to identify a user on a machine. The server is running a Linux-based operating system if the Linux commands are successful in being performed.
An attacker can submit various commands into each of the input fields found in a program, and those commands will be executed if the application has several different input fields. Now, an attacker can quickly retrieve sensitive information from the server if the program does not handle input validation appropriately. For instance, we are obtaining the value of “whoami” in the command that comes before it. When the application does not handle input validation effectively, this occurs.
Because input validation has not been properly done, there is a chance that SSI injection will occur. The input can very easily execute the server’s instructions.
The web server executes the script locally while the input is being processed through the website’s input fields. After that, the script can be used to manipulate code. The web server would process the HTML page first, followed by any Server-side Include statements that were present, before delivering content to the user’s browser.
Why is Server Side Injection a danger?
SSI injection is risky because it has the potential to develop into remote code execution (RCE) or because it gives an attacker access to the server’s shell, which gives him or her full control over the server and lets them run command snippets at will. These two results are detrimental. Due to the relatively simple execution of the server directive, access to the server files, and the potential to extract sensitive data from the server, this vulnerability has been given a High severity rating.
If a user wishes to retrieve data from an operating system that is based on Unix.
The following string can be used by a user to retrieve confidential data from database connection strings in a .Net configuration file:
The snippet below will return the value of the variable if the user requests to retrieve its value.
If the user wishes to utilize an include directive to retrieve data from a CGI script. This directive can be used to retrieve the content of a file or list of files from the directory and includes the output of CGI Script.
The user can use the command listed below to retrieve output using system commands.
How effective is the Server Side Injection directive?
The URL extension, which should be a .stm, .shtm, or shtml, is the first thing we look for when determining whether an application is susceptible to SSI injection. Next, we enter the characters one at a time into the input areas marked with an [a-zA-Z0–9]”->.
The attacker will examine each webpage to see if it accepts user input, how it processes and stores that input, and whether or not it displays an error message when the user enters incorrect information or makes any other changes to the webpage. The attacker will fill the input fields with every possible SSI directive (based on the information provided by the server’s operating system). Investigate the code in the linked link to learn more about how the input is handled.
Once an attacker has complete control over every potential site for injection, the attacker will submit the input, and the web server will then receive it. The web server will now execute and parse the data or information before sending the requested web page to the client’s browser. The user will be able to see that the attack was successful when they reload the website.
As an illustration, when a user intercepts communication using a tool like Burp Suite, he might change the request header to suit his needs. If the request header appears as follows:
Now that the user wants to retrieve some data or conduct server-side system functions, he may change the request header. He can change the request header to look like this:
The attacker will immediately receive access to the sensitive Linux password file’s contents after the aforementioned command has been executed.
How might SSI be mitigated?
- User input must be sanitized, thus before it is sent to the page with SSI execution permissions, the HTML entity must be encoded
- If certain pages call for the SSI, the team must take certain actions, such as:
- To prevent or lessen the impact of SSI injection, it is important to disable the exec directive on the server. In the future, if there is no need for it, you should disable SSI execution on the person’s web pages
- Don’t enable all SSI directives; instead, only those that the page specifically needs
Use the SUExec command to make the user the file’s owner instead of the web server user.
- If there is no legitimate business need for it, disable HTML page uploads; otherwise, an attacker might use SSI directives to control the upload. If a user’s data dynamically loaded HTML pages, the content of the HTML page in question must first be correctly encoded before it can be displayed.
Server side template injection: what is it?
When an attacker is able to inject a malicious payload into a template using native template syntax, the template is subsequently executed server-side. Web pages are created by template engines by fusing static templates with ephemeral data.
Server – side template injection payloads
Server side template injection payloads are when an attacker is able to inject a malicious payload into a template using native template syntax, and the template is subsequently executed server-side.
Web pages are created by template engines by fusing static templates with ephemeral data. When user input is combined into a template directly rather than being given in as data, server-side template injection attacks can happen. As a result, attackers can manipulate the template engine by injecting arbitrary template directives, frequently giving them full control of the server. In contrast to traditional client-side template injections, server-side template injection payloads are supplied and analyzed on the server, as the name implies, possibly making them far more dangerous.
Server side includes injection is a technique used by Web applications to provide dynamic material to HTML pages. They are comparable to CGIs, however, SSIs are used to carry out some operations either before the current page loads or as it is being visualized. To accomplish this, the web server examines SSI prior to delivering the page to the user.
Although SSI attacks are less well-known than other online application injection techniques like SQL injection, they do exist. We are accustomed to SSI attacks. By running the shell commands and obtaining extremely sensitive data from the server, such as configuration files and password files, attackers can exploit the high severity vulnerability on the server.
Attackers can therefore take advantage of the vulnerability as a result. The complete SSI directive must be deactivated until it is no longer required, thus the owner of the application and the server administrator must make sure of it.