Inside the Briefcase

Solving the steam_api.dll Missing Issue

Solving the steam_api.dll Missing Issue

Usually this error is faced by the gamers -...

How Security in Tech is Being Reinforced

How Security in Tech is Being Reinforced

In an increasingly digital world, security has become a...

2022 Business Spend Management Benchmark Report

2022 Business Spend Management Benchmark Report

Read the 2022 Coupa Benchmark Report to explore 20...

Cloud Security: Understanding “Shared Responsibility” … and Keeping Up Best Security Practices

Cloud Security: Understanding “Shared Responsibility” … and Keeping Up Best Security Practices

Cloud computing has been around for many years now,...



Join data & analytics leaders from Starbucks, Cardinal Health,...

Server-Side Injection Attacks: What You Should Know

November 22, 2022 No Comments

by Uzair Nazeer

An injection flaw is essentially a vulnerability that lets the attacker gain control over something or make exploits on the server side. For example, think of a login form that is tied to a database in the backend. This form performs queries on the database to validate if the user is who they claim to be. 

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.


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.


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.

Click here to view more IT Briefcase content!


Sorry, the comment form is closed at this time.