What are injection flaws and why are they a web application risk?

What are injection flaws?

Injection flaws refer to a range of attacks in which a threat actor submits unexpected inputs into a web application. To do this, the attacker injects malicious code into the application, often via a text field, URL or perhaps an upload that is parsed by the system, for example, an XML document.  

An injection attack can occur in any instance where the user input is accepted by the application and processed without proper sanitisation. This enables the attacker to influence how the web application constructs commands and queries and the data it generates. These attacks typically result in data or session theft, denial of service, or a compromised back-end system.  

The injection vulnerability category is currently in third place in the  OWASP Top 10. These flaws are one of the most prevalent risks in web applications today. They are often not complicated for malicious actors to attempt and can have far-reaching consequences. For example, the infamous TalkTalk breach of 2016, which resulted in the sensitive data of 150,000 customers being stolen, occurred because of an SQL injection.  

Types of injection attacks

Injections are a broad class of attack vector. Below, we explain some of the most common types of injection attacks.  

SQL injection 

In an SQL injection attack, a malicious actor will inject an SQL query through the input of data from the browser to the application. If successful, the attacker may be able to access and alter sensitive data from the client’s database and, in some cases, execute administrative commands. 

In practice, these attacks can enable attackers to forge identities, trigger issues like voiding transactions or changing balances, destroy data or make it unavailable, and perform administrative tasks in the database.  

These attacks can be more common in PHP and ASP applications due to their legacy functionality. The use of modern frameworks and libraries can make an application less prone to SQL injections, as many of these frameworks have built-in safe functionality for performing queries. However, custom code can still override or misuse this functionality. 

Cross-site scripting 

A cross-site scripting (“XSS”) attack is a form of injection attack in which a threat actor is able to insert malicious code into an otherwise benign website. The malicious script targets the web application’s content and is then delivered to end-users browsers as they interact with the application – and the victim is often none the wiser. 

This potentially enables the threat actor to access any of the user’s website data, cookies and even take over the session. If the user has administrative access to the application, the attacker could leverage this to grant themselves administrative control, or potentially exploit the application’s underlying functionality through the abuse of administrative controls.  

Typically, cross-site scripting attacks can be considered “stored” or “reflected”. In the former, a harmful script lurks permanently within the application., until the browser processes a request for the stored data. 

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

XPath injection 

An XPath injection occurs in applications that use user-supplied data to construct an XPath query for XML data. The attacker will send corrupted data to the application to discover how the XML data is structured or to access data that should be prohibited.  

With this attack type, attackers can also potentially elevate their access privileges if the XML data is used for authentication.  

Mail command injection 

In a Mail Command Injection attack, an attacker will exploit mail servers and web applications that utilise IMAP/SMTP statements from the user-generated input. These servers are not usually accessible directly from the internet.  

If the input is not sanitised before being sent to the email library, then the input is vulnerable, and the attacker maybe is able to introduce new commands into the message, thus ordering the mail server to perform in a different way than expected. 

Internal mail servers tend to go through less security hardening than external-facing infrastructure, meaning mail command injection attacks can yield high results for the attacking team.  

CRLF injection 

A CRLF injection occurs when a threat actor inserts a CRLF character sequence where it is not anticipated in an HTTP stream where the data input is not correctly sanitised. These attacks can be used to split HTTP response headers, known as HTTP response splitting.  

CRLF injections enable attackers to trick web application functionality so that it performs unexpectedly. This may allow the attacker to modify the application data, view and steal sensitive data, compromise the application’s integrity and enable further exploitation in the form of, for example, proxy and web server cache poisoning and website defacement. 

Host header injection 

In an HTTP host header attack, an attacker will exploit vulnerable applications that fail to utilise the value of the host header safely. If the server trusts the user-supplied host header, an attacker can use this input to insert malicious payloads that manipulate server-side behaviour without proper validation.  

These attacks tend to occur because organisations do not realise that the host header is user-controllable. Without the proper validation, it is vulnerable to host header attacks that can, in turn, be used for web cache poisoning and routing-based server-side request forgery. 

LDAP injection 

LDAP injection attacks occur when user-controllable data is shared with an LDAP query in the application. The attacker will insert LDAP metacharacters into the query in order to interfere with the query’s function.  

Depending on the exact query’s function, an attacker may be able to retrieve sensitive data they should not be able to access or to alter the application’s logic to perform an unexpected action.  

Why do injection flaws happen?  

Most often, injection flaws are the result of business logic and input sanitisation vulnerabilities. These are essentially weaknesses in the design and operation of an application that enable malicious actors to manipulate its functionality. Business logic flaws are common in the fast-paced world of web development.  

Developers today are often time-pressed. Creating and maintaining an application without introducing a single vulnerability is practically impossible. Moreover, application developers often fail to anticipate how an attacker may use an application atypically. They instead focus on the intended functionality for the end-user.  

These assumptions can result in a failure to validate user inputs, leading to injection vulnerabilities that attackers can exploit. This means that when an attacker interacts with the user input unexpectedly, the application cannot prevent their action, as no safeguards are in place.  

How to mitigate injection flaws

To avoid such weaknesses, developers must take a more holistic approach to development, including an awareness of how user inputs can be used in unexpected ways. Guidelines such as OWASP’s injection resources should be considered during the development phase.  

While the development industry is, broadly, shifting left, some vulnerabilities will always arise. Web applications, after all, are rarely static. Vulnerabilities will still slip through the net at some point or another.  

As an assurance method, organisations should also implement regular vulnerability scanning combined with manual web application penetration testing to improve their security posture.  

Automation in tools, such as Burp Suite and OWASP Zap, can discover some – but not all – injection flaws, while manual penetration testing will find more complex weaknesses. We recommend implementing monthly vulnerability scanning along with penetration testing at an annual interval – or after a significant change to the application.  

For more information on this topic, please refer to our blog on authenticated web app penetration testing and our broader guide to the different types of penetration test.  

Need a penetration test?

If your organisation needs help running a penetration test on an application or infrastructure, we’re here to help. We can assess your environment and run a full penetration test. We can also advise you on any follow-up actions or remediations from our findings.