Top 5 injection attacks in application security

What are injection attacks?

Injection attacks refer to any type of attack that targets injection vulnerabilities—a broad category of cybersecurity weaknesses that includes several of the most serious application security risks. While you could argue it’s an artificial way to group otherwise unrelated attacks, the OWASP Top 10 for 2021 took this exact approach, naming injection the #3 overall risk category for web application security instead of listing specific vulnerabilities as in previous editions.

Despite the wide variety of attack vectors, the common denominator for injection attacks is that attackers are able to insert payloads into executed application code via unvalidated user input. Depending on the specific vulnerability and the attack target, injection may involve database queries, JavaScript code, native application code, operating system commands, and so on. When successful, injection attacks can have a wide variety of consequences, from revealing less sensitive information to more serious data breaches, denial of service, privilege elevation, authentication bypass, or even remote code execution and potentially full compromise of a target system.

#1 injection attack: SQL injection (SQLi)

Most web applications are backed by databases of some sort, with many relying on standard relational database management systems that use SQL as their data access and query language. SQL injection attacks are performed by including an SQL statement in data sent via a web form, comment field, query string, parameter, or another input channel accessible to external users. The malicious code can be an SQL query designed to extract sensitive data or an SQL statement aimed at modifying database content by adding or deleting records or even entire database tables. Malicious hackers often target user records to add a privileged user or elevate privileges for an existing account.

An application that has an SQL injection vulnerability incorporates user-controllable input in the SQL statements it builds. The resulting query is sent to the database server without sufficient validation or encoding and executed, including any malicious SQL statements injected by the attacker. When the vulnerable application doesn’t return data directly, attackers may use blind SQL injection to discover information indirectly.

SQL injection vulnerabilities correspond to CWE-89: Improper Neutralization of Special Elements used in an SQL Command in the Common Weakness Enumeration, with SQL injection listed at #3 on the CWE Top 25 for 2023. Invicti’s DAST tools can automatically detect many types of SQL injection vulnerabilities, from typical in-band SQL injection (including UNION injections) to blind SQL injection (including Boolean-based) and out-of-band SQL injection.

See our SQL injection cheat sheet for a detailed discussion of SQL injection attacks, including payload examples for popular SQL databases.

#2 injection attack: Cross-site scripting (XSS)

While it doesn’t have “injection” in the name, cross-site scripting (XSS) is all about exploiting script injection vulnerabilities. If a web application fails to sanitize user-supplied inputs that include script code (usually JavaScript), it may be vulnerable to XSS. To exploit an XSS vulnerability, the attacker supplies a string that contains malicious code, typically by including it as a request parameter value. Instead of processing that value as expected by application logic, a vulnerable application executes the provided script payload in the victim’s browser.

Though sometimes dismissed as low-risk and limited to a single user session, XSS attacks can have serious consequences, especially when used in a longer attack chain. What’s more, with full-stack JavaScript applications now also running on the server side with Node.js, the impact of XSS no longer has to be limited to the browser. User input filtering alone is not enough to prevent XSS, as there are many ways of evading XSS filters, so following secure coding practices and restricting script sources using Content Security Policy are recommended to prevent XSS.

XSS is listed as CWE-79: Improper Neutralization of Input During Web Page Generation in the CWE classification and was ranked the second most dangerous software weakness in the CWE Top 25 for 2023. Invicti DAST can detect and automatically confirm many types of XSS vulnerabilities, including reflected XSS, stored (persistent) XSS, and DOM-based XSS.

Listen to Episode 1: Hot Cross-Site Fun from Invicti’s AppSec Serialized podcast to learn all about cross-site scripting and real-life XSS attacks!

#3 injection attack: OS command injection

Web applications may sometimes need to execute operating system commands, for instance to read or write files on the web server. For an application with an OS command injection vulnerability, attackers can hide malicious system commands in user inputs and have the application execute them on the server. Successful command injection (also called shell injection) can be extremely dangerous, allowing attackers to obtain information about system and server configuration, escalate user permissions, or execute arbitrary system commands to fully compromise the system.

Because the consequences can be so serious, it’s good practice to avoid calling system commands that include user-controllable data in your web applications. When executing a system command is necessary, be sure to carefully validate all its inputs and restrict them to specific permitted values.

OS command injection was ranked at #5 in the CWE Top 25 list as CWE-78: Improper Neutralization of Special Elements Used in an OS Command. Invicti DAST scanners can detect several variants of command injection vulnerabilities, including blind and out-of-band command injection.

#4 injection attack: Code injection (remote code execution)

Your application has a code injection vulnerability (aka remote code execution or RCE) if an attacker can include application code in user input and get your app to execute it. The difference compared to OS command injection is that you are injecting application code, not system commands (though the two can occur together if an application accepts malicious code that then calls a system command). For example, code injection into a vulnerable application written in PHP will involve PHP code, while a vulnerable Java app would be injected with Java code.

While most code injection vulnerabilities are only exploitable as part of a longer attack chain, RCE is considered the holy grail of application security testing because if an attacker manages to get remote code execution, they can do more or less anything they want, so the target system is considered fully compromised. While the specific severity rating depends on the ease of exploitation, RCE vulnerabilities are nearly always critical.

Code injection is officially classified as CWE-94: Improper Control of Generation of Code. Invicti’s vulnerability scanner can detect and often automatically confirm dozens of code execution and code evaluation vulnerabilities across a variety of programming languages and frameworks.

#5 injection attack: XXE injection

To round out this top five, let’s look at something slightly different: XML external entity (XXE) injection. XML documents are used in all sorts of web application requests and if an app that accepts XML inputs is configured to support legacy document type definitions (DTDs) with weak XML parser security, attackers can use specially crafted XML documents to perform XXE injection. This breaks the XML parser and can be used for further cyberattacks ranging from directory traversal to server-side request forgery (SSRF) or even remote code execution.

While the first four injection attacks discussed here rely on failures in user input validation, XXE takes advantage of inherently unsafe legacy functionality in XML parsers. Because this is more a case of insecure configuration than insecure code, XXE can sometimes evade detection, making it particularly dangerous. If your application processes XML documents, the only way to avoid XXE vulnerabilities is to disable support for DTDs or (if you have to use them) at the very least disallow the use of external entities.

Attack vectors related to XML external entities fall under CWE-611: Improper Restriction of XML External Entity Reference. XXE injection used to have its own spot at #4 in the OWASP Top Ten for 2017 but was merged into the Security Misconfiguration category for the 2021 edition. Invicti’s web vulnerability scanner detects many XXE injection vulnerabilities, including out-of-band XXE injection.

Other common injection attacks

The top five above represents the most common injection vulnerabilities found in applications and APIs today, but several less frequent injection attacks also deserve a mention:

• NoSQL injection attacks follow the same principle as SQL injection but target databases that don’t use SQL queries, such as MongoDB, Cassandra, or Elasticsearch. Because there is no standard query language for NoSQL databases, NoSQL injection payloads are different for each type of database server.
• JSON injection attacks are closely related to XSS but instead of injecting script code, attackers attempt to insert or modify JSON data sent or received by the application. This injection technique is especially useful when attacking REST APIs, where JSON is the dominant data format.
• Server-side template injection (SSTI) attacks target server-side template engines used to dynamically generate web page code. If attackers are able to inject expressions in the relevant template language, their malicious code will be included in the page HTML. Expression language injection is a related risk, this time injecting expressions specific to a web framework rather than a template engine.
• HTTP header injection (CRLF injection) is possible when an application accepts newline characters in input that then goes directly into an HTTP header. HTTP requests use a newline to separate the request header and body, so injecting newline characters may allow an attacker to replace the legitimate response body with HTML data that includes malicious code such as an XSS payload.

Preventing injection vulnerabilities and attacks

Apart from XXE, all the injection attacks listed here rely on the web application accepting and executing unsanitized user inputs. The underlying security issue is improper input validation and its own place in the CWE Top 25 list, right up at #4. By properly sanitizing, filtering, and encoding all user-controlled inputs to your app, you can prevent the vast majority of trivial injection vulnerabilities. Setting the right HTTP security headers and CSP rules will also block many avenues of external attack right out of the gate.

Developers should know and use secure input processing features in modern web frameworks and languages. Most SQL injection attacks can be prevented by using parameterized queries or server-side prepared statements (aka stored procedures), while application frameworks such as React provide built-in constructs that make it all but impossible to write code vulnerable to XSS (unless you deliberately bypass all the built-in safeguards).

Vulnerabilities can always crop up both in new and updated code, and new ones discovered on code previously considered safe, so it’s vital to consistently test your entire exploitable attack surface. The recommended practice is to regularly and automatically scan all your web applications and APIs with a high-quality dynamic application security testing solution that is integrated both into your development lifecycle and your security operations.

See our white paper to learn how you can integrate DAST into your SDLC.