by Uzair Nazeer
During an injection attack, the attacker manipulates the data sent to the backend to gain unauthorized access or change the database, which may harm other users’ data.
SQL injection is a popular server-side injection attack in which the attacker writes a string that can be executed as a valid database command, usually by closing the hardcoded string and starting a new line of string. This is made possible when there is no data sanitization protocol in place.
Scope of Testing in Server-Side Attacks
Testing plays a major role in preventing server-side attacks, specifically SAST (static application security testing). This analysis helps in identifying security vulnerabilities directly in the source code. SAST takes place in the early stages of an SDLC. Additionally, it doesn’t require the code to be compiled, meaning one can look for security vulnerabilities without breaking builds, saving time and quickly resolving issues.
Difference between SSI attacks and XSS
When we define server-side includes (SSI) injection attacks and cross-site scripting (XSS), there is a fine line between their objectives and functions, and it is important to understand them. The main difference between the two is at what phase the attack is executed. While an injection attack commonly targets the system’s backend, a cross-site scripting attack occurs on the client side.
When data entered into an application is re-displayed in the browser without being sanitized, a cross-site scripting vulnerability occurs. This indicates that rather than an attacker injecting code to harm a server, the code is used to harm a user. However, the attacker convinces the user to pass the code rather than directly send it to the application. This code is then returned to the user in a form that their browser interprets as though it were an original component of the page.
How is it carried out?
Before hopping on to the working of the injection, let us first try to understand what are server side include(s).
SSIs are directives that can be found in the HTML code of a webpage and are used to add dynamic content to HTML pages. For example, consider a web application with numerous pages, each requiring a unique header and footer. Instead of manually coding for each of these, SSIs can be used in the HTML to dynamically inject the necessary content into each page.
It has the following syntax:
<!– #directive parameter=value parameter=value →
All directives are identified by “#”.
Unless SSI is enabled on the server, all the SSIs are placed within an HTML comment which is not visible in the source code.
Caveat
The pitfall of SSIs is that they can execute Linux commands to alter, add & remove data on the server.
The first step in attacking involves checking the vulnerability of the web application. This is simply confirmed by checking if the sent data is validated or not. To further confirm the vulnerability, the attacker could send non-harming commands to ensure everything is working as expected. Once the server responds with the attacker’s desired result, they will start sending malicious commands to perform the attack.
Remediation Techniques
Although server-side attacks might seem to be pretty flawed, some remediation methods can withstand such common attacks.
The most basic way to avoid injection attacks is by sanitizing input and output data. While input data validation is quite known, it is also important to sanitize data before it is displayed to the user. Validating input data ensures the input is bound within the allowed set or combination of characters. On the other hand, output data sanitization confirms that the client executes no malicious code or command.
Performing a thorough test, preferably a static application security test on the application, is advised as it has the potential to uncover vulnerable code of the application, which can be immediately addressed and fixed. Another common way to avoid SSI attacks is to simply not use server-side includes in the application architecture.
Avoid using .shtml and .shtml pages. Though it is possible to configure SSI for .htm and .html pages, it makes it easier for the attacker to discover the vulnerability if .shtm or .shtml pages are used.
Conclusion
So that’s a brief overview of SSI injection. Although it’s rather straightforward, it has significant ramifications. Fortunately, it isn’t as widespread an attack as it previously was because there are now other ways to provide the functionality offered by SSIs. But, as a rule of thumb, it is always advised to sanitize input data both on the client and server side to avoid such attacks.
