What are injection attacks?
Injection attacks target injection vulnerabilities – a very broad category of cybersecurity flaws that includes some of the most serious application security risks. In fact, the OWASP Top 10 for 2021 lists injection as the #3 overall risk category for web application security. Despite the wide variety of attack vectors, the common denominator for nearly all injection attacks is that attackers are able to insert unvalidated user input directly into executed application code.
Depending on the type of vulnerability and goal of attack, an attacker might inject database queries, JavaScript code, native application code, operating system commands, and so on. A successful injection attack can have a variety of consequences, including a data breach, denial of service, privilege elevation, authentication bypass, or even the complete compromise of a target system via remote code execution.
#1: SQL injection (SQLi)
The vast majority of web applications are backed by databases, with the most popular database management systems still using SQL (Structured Query Language) as their data access language. To perform an SQL injection attack, a malicious hacker slips an SQL statement into data entered in a web form, comment field, query string, or another input channel accessible to external users. The malicious code is usually an SQL query designed to extract sensitive data, but it can also be an SQL statement aimed at modifying database content, up to and including deleting (dropping) database tables.
If the target application is vulnerable to SQL injection, it will send this data directly to the database without checking if it’s safe. Then, instead of storing a comment or retrieving some account data, the database server will execute malicious SQL statements injected by the attacker. Even if the vulnerable application doesn’t expose data directly, attackers may use blind SQL injection to discover information indirectly.
SQL injections are among the oldest and most dangerous web application vulnerabilities. Listed in the Common Weakness Enumeration as CWE-89: Improper Neutralization of Special Elements used in an SQL Command, SQL injection comes in at #6 on the CWE Top 25 for 2021. Invicti detects many types of SQL injection vulnerabilities, from typical in-band SQL injection 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, complete with payload examples for several popular SQL database management systems.
#2: Cross-site scripting (XSS)
While it doesn’t have “injection” in the name, cross-site scripting (XSS) is, in essence, a script injection vulnerability. Any web application that fails to sanitize user-supplied inputs that contain script code (usually JavaScript) could be vulnerable to cross-site scripting (XSS). To exploit an XSS vulnerability, the attacker provides a text string that contains malicious code, for example putting it in the URL as the user ID parameter. Instead of being treated as a regular parameter value, the attack payload is then executed by the victim’s browser.
XSS attacks can have serious consequences, from redirecting the user to a malicious site to stealing session cookies and hijacking the user session. While user input filtering can somewhat reduce the risk of a successful attack, there are many ways of evading XSS filters, so writing secure code is always the recommended line of defense.
XSS is listed in the CWE weakness classification under CWE-79: Improper Neutralization of Input During Web Page Generation and was ranked the #2 most dangerous software weakness in the CWE Top 25 for 2021. Invicti detects several kinds of XSS vulnerabilities, including stored (persistent) XSS and DOM-based XSS.
#3: OS command injection
Web applications may occasionally need to execute system commands in the underlying operating system. If the application has an OS command injection vulnerability, attackers are able to provide their own operating system commands in user inputs. Successful command injection (aka shell injection) can be extremely dangerous, as it can allow attackers to obtain information about the operating system and server configuration, escalate their permissions, or even execute arbitrary system commands to fully compromise the system.
Prevention is always better than cure, so it’s good practice to avoid calling system commands from web applications wherever possible. When executing a system command is necessary, always carefully validate user inputs and tightly restrict them by whitelisting.
OS command injection came in at #5 in the CWE Top 25 list as CWE-78: Improper Neutralization of Special Elements Used in an OS Command. Invicti detects several variants of command injection vulnerabilities, including blind command injection and out-of-band command injection.
#4: Code injection (remote code execution)
If attackers are able to provide application code as user input and get the server to execute it, your application has a code injection vulnerability (aka remote code execution, or RCE). For example, if the vulnerable application is written in PHP, attackers can inject PHP code that gets executed by the PHP interpreter on the web server.
Note that code injection is different from OS command injection because you are injecting application code, not system commands (although one can lead to the other if your application accepts malicious code that calls a system command). If the attacker manages to get remote code execution, the target system should be considered compromised, so this is a critical vulnerability.
Code injection is classified under CWE-94: Improper Control of Generation of Code. Invicti detects dozens of code execution and code evaluation vulnerabilities across a variety of programming languages and frameworks.
#5: XXE injection
Closing off this top 5 is XML external entity (XXE) injection. If an application accepts XML inputs and is configured to support legacy document type definitions (DTDs) with weak XML parser security, attackers can send it specially crafted XML documents to perform attacks ranging from directory traversal to server-side request forgery (SSRF) and remote code execution.
Unlike the previous four injection attacks, this one does not exploit unvalidated user input but inherently unsafe legacy functionality in XML parsers, so it can be particularly dangerous. If your application processes XML documents, the only way to avoid this vulnerability is to disable support for DTDs, or at the very least for external entities.
Attack vectors related to XML external entities are classified as CWE-611: Improper Restriction of XML External Entity Reference. While listed at #4 in the OWASP Top Ten for 2017, XXE injection has been merged into the Security Misconfiguration category in 2021. Invicti detects XXE injection vulnerabilities, including out-of-band XXE injection.
Other common injection attacks
This post only scratches the surface of web application injection attacks, so here are a handful of (dis)honorable mentions that didn’t make the top five:
- Server-side template injection (SSTI) attacks target template engines that are used to dynamically generate web page code based on server-side templates. If attackers are able to input expressions in the relevant template language, their malicious code will be included in the page HTML. Expression language injection is a related category of attacks, with attackers injecting expressions specific to a web framework rather than a template engine.
- HTTP header injection (CRLF injection) is possible if an application accepts newline characters in input that goes directly into an HTTP header. Because HTTP requests use a newline to separate the header and body, injecting newline characters may allow an attacker to tamper with the HTML data returned by the server, for example to add malicious JavaScript for XSS.
- NoSQL injection attacks follow the same principle as SQL injection but target databases that don’t use SQL, such as MongoDB, Cassandra, or Elasticsearch. Unlike SQLi, where very similar attacks can be used against multiple server products, NoSQL injection requires dedicated attack payloads for each type of database server.
Preventing injection attacks
All but one of the injection attacks listed above rely on untrusted input being executed by the web application. Unsurprisingly, improper input validation has its own place in the CWE Top 25 list, right up at #4. Careful sanitization, filtering, and encoding of all user-controlled inputs can help to prevent the vast majority of injection vulnerabilities.
Crucially, developers should know and use secure input processing mechanisms provided by modern web frameworks and languages. For instance, SQL injection is easily prevented by using parameterized queries or server-side prepared statements (aka stored procedures). And with frameworks such as React, writing code that is vulnerable to XSS is only possible if you deliberately bypass the built-in safeguards.
To minimize your exploitable attack surface across frequent application changes and new attack methods, it is recommended practice to regularly and automatically scan all your web applications and APIs with a high-quality application security testing solution integrated directly into your development lifecycle. See our white paper to learn how you can integrate vulnerability scanning into the SDLC.
