Web Application Injection Attack Types Guide

Online attacks have evolved since the internet’s earliest days. Back then, brute force was a go-to solution for bots or individuals with the time to try countless login combinations before they stumbled upon the right ones to enter an application.

However, such brutish attacks pose no issue to users today, due to the proliferation of complex password policies, captchas, etc. Still, cybercriminals still work hard to identify system vulnerabilities and exploit them via new attack types.

This is how injection attacks emerged not so long ago: hackers found that text fields on website pages or applications could be tricked by typing (or “injecting”) unexpected data into them. This would lead the application to take an action it wasn’t meant to.

These injection attack techniques can be employed to enter an application without key access details, and to release personal data. Hackers may even use injection attacks to hijack servers for their own nefarious goals.

That’s why injection attacks pose a threat to applications and those users whose information is contained within. Other connected services or applications could be at risk, too.

In this post, we explore the nine most popular types of injections to help you stay vigilant.

Types of injection attacks

Code injection

A code injection is one of the most popular types of injection attack endangering businesses’ and users’ data. Any hackers which know a web application’s framework, programming language, OS, or database can enter a malicious code into available fields. This enables them to make the webserver behave as they’d like it to.

Code injections tend to be viable on applications with no validation for data entered into a text field. If it allows users to put any information they like into a field, the application can be exploited. That’s why applications have to control what details users can submit as much as possible.

Such tactics may involve limiting the characters accepted or checking the format in which data is entered. Vulnerability to code injection can be simple to identify by inputting different forms of content into a text field. If a hacker is able to exploit a weakness in the code, they may compromise the application’s performance, data confidentiality, and more.

SQL injection

Attackers perform SQL injections by putting an SQL script into a text field, which is passed on to the application and executed. This means attackers can get through entry screens and even gain access to confidential data from an application’s database. They might be able to conduct administrative tasks and change or destroy information.

Applications based on ASP or PHP tend to be at risk of SQL injections because their interfaces are less sophisticated than more updated alternatives (such as ASP.Net or J2EE builds). Attackers can wreak major havoc on applications when they find SQL injection opportunities.

Command injection

Hackers can take advantage of weak validation on input data for command injections, which are different from code injections because the attacker uses system commands rather than scripts or code.

This means that the cybercriminal responsible has no requirement to understand the application’s programming language or that of the database itself. However, hackers do have to be familiar with the hosting server’s OS to be successful.

Any commands inserted will be executed by the OS. As a result, attackers can expose various forms of data, adjust passwords to leave users locked out, and more. However, companies can prevent such attacks with a sysadmin, tweaking the access level for applications running on their server.

Cross-site scripting

Any application which inserts user input in its output without encoding or validating it first creates a chance for a hacker to distribute malicious code to a different user — a move known as cross-site scripting.

Otherwise known as XSS attacks, these involve seizing opportunities to inject harmful scripts into websites which have trust and ultimately sending them to an application’s different users.

For those on the receiving end, their browser will go on to execute the harmful script. Both the user and the browser will have no idea that the script is dangerous. All cookies, sensitive data, and more can be accessed. HTML files may even be targeted, with malicious scripts potentially rewriting some of their content before the user realizes anything’s wrong.

Typically, cross-site scripting attacks can be considered “stored” or “reflected”. In the former, a harmful script lurks on a permanent basis, whether in a server, forum, database, etc., until the browser processes a request for the data stored.

In the latter type, harmful scripts are reflected in responses which include input transmitted to the target server, in the form of a search result or warning message.

XPath injection

Hackers can employ this type of cybersecurity attack when an application utilizes a user’s information to create an XPath query for XML data. These function in a similar manner to the SQL injections covered above — an attacker will distribute corrupted data to an application to identify the way in which its XML data is built. They use a subsequent attack to access the XML data.

As with SQL, XPath is a language in which attackers can specify which attributes they wish to find. Applications utilize a user’s input to create a pattern which the data is supposed to match, and turn this into a process which the hacker aims to apply to the relevant data.

However, unlike SQL, XPath injections can be used on applications relying on XML, no matter how it’s implemented. As a result, hackers can use automated attacks and work towards any number of goals.

Mail command injection

Cybercriminals may choose to leverage this form of attack to take advantage of email applications or servers which build SMTP or IMAP statements with user input which has not been validated effectively.

This is because both types of servers often lack adequate defenses against hackers, and by gaining access to systems via email servers, attackers can avoid security measures (captchas, for example).

So, how do attackers exploit SMTP servers for their own gain? They require a working email account to distribute messages containing injected commands. Vulnerable servers tend to respond to these requests and allow them to override restrictions. Hackers can use it to bombard recipients with spam, further expanding their reach.

With IMAP injection, attackers can exploit applications’ message-read capabilities. All they have to do is submit a URL with relevant injected commands into a web browser’s bar.

CRLF injection

This occurs when an attacker inserts a carriage return and line feed characters (CRLF) in fields on website forms. Those characters (which are invisible) show command or line ends in most standard protocols, including NNTP and HTTP.

As an example, inserting a CRLF and some specific HTML code into an HTTP request could lead a website’s visitors to see custom pages. Attackers can target vulnerable applications which fail to filter user input effectively. This opens a site up to other injection attacks (code injections, XSS) and may lead to it becoming hijacked.

Host header injection

Host headers are essential for servers which host a large number of applications or websites, to identify which of them should process requests coming in. A header’s value informs the server which of the sites or applications should receive the request.

When an invalid host header goes to a server, this is typically sent to the first application or website on the list. This creates a weakness which attackers can leverage to send host headers and manipulate systems.

This is most common with PHP applications, but it can be performed with a variety of web development technologies too. Host header attacks open the door for other attack types, including web-cache poisoning, and could cause negative effects like resetting passwords.

LDAP injection

Finally, let’s talk about LDAP injection.

This is a protocol built to enable resource searching within a network, such as browsing files, devices, etc. Intranets, for example, benefit from this. When applied as a component in a single sign-on system, LDAP injection facilitates the storage of individual passwords and usernames.

An LDAP query involves using specific characters to affect its control, and hackers can transform a query’s behavior by adding their own characters. This is down to ineffective validated user input: if a user enters text into an application before it’s been sanitized, the resulting query may bring up a user list for an attacker to see.

All they’d have to do is place an asterisk in a particular place within an input string.

How to defend against popular types of injections

Injection attacks are targeted at applications and servers with open access to online users, and so application developers and server admins must take responsibility for taking preventative measures.

Developers must recognize dangers related to ineffective user input validation and the best ways to sanitize input to prevent risks. Server admins have to conduct regular audits to pinpoint weaknesses and address them.

No comment yet, add your voice below!

Add a Comment

Your email address will not be published. Required fields are marked *


  • Yes, please, I agree to receiving my personal Plesk Newsletter! WebPros International GmbH and other WebPros group companies may store and process the data I provide for the purpose of delivering the newsletter according to the WebPros Privacy Policy. In order to tailor its offerings to me, Plesk may further use additional information like usage and behavior data (Profiling). I can unsubscribe from the newsletter at any time by sending an email to [email protected] or use the unsubscribe link in any of the newsletters.

  • Hidden
  • Hidden
  • Hidden
  • Hidden
  • Hidden
  • Hidden

Related Posts

Knowledge Base

Plesk uses LiveChat system (3rd party).

By proceeding below, I hereby agree to use LiveChat as an external third party technology. This may involve a transfer of my personal data (e.g. IP Address) to third parties in- or outside of Europe. For more information, please see our Privacy Policy.