Injection Attacks Overview

Injection attacks occur when an application passes untrusted user input to an interpreter (such as a SQL database, operating system shell, LDAP directory, or XML parser) without proper sanitization or validation. The attacker crafts input that contains both data and executable code, and the interpreter executes the code as if it were a legitimate command. The core vulnerability is the failure to separate data from code.

Injection exploits the fact that many interpreters use special characters to delimit commands or query structures. For example, in SQL, the single quote (') marks the start or end of a string literal. If an application constructs a SQL query by concatenating user input directly, an attacker can inject a single quote to break out of the intended string and then append malicious SQL commands.

Example of vulnerable code (SQL injection):

# Vulnerable Python code
username = request.GET['username']
query = "SELECT * FROM users WHERE username = '" + username + "'"
cursor.execute(query)

If an attacker enters ' OR '1'='1, the query becomes:

SELECT * FROM users WHERE username = '' OR '1'='1'

This returns all rows because '1'='1' is always true.

Real-world example (CVE-2021-41773): A path traversal vulnerability in Apache HTTP Server 2.4.49 allowed attackers to map URLs to files outside the document root. While not classic injection, it shares the concept of insufficient input validation leading to unintended execution.

Example (safe code):

cursor.execute("SELECT * FROM users WHERE username = %s", (username,))

A SOC analyst at a retail company notices unusual database queries in the logs. The logs show a query like SELECT * FROM products WHERE id = 1 UNION SELECT credit_card_number, expiry, cvv FROM payments. The analyst traces the source IP to a user's search request. The application's product search endpoint directly concatenated user input into a SQL query. The attacker had extracted thousands of credit card numbers over several hours. The correct response is to immediately block the IP, take the vulnerable endpoint offline, and conduct a forensic analysis. The analyst should also check for data exfiltration patterns (e.g., large outbound data transfers). A common mistake is to only patch the vulnerability without checking for existing backdoors or compromised accounts.

An engineer receives an alert from the IDS indicating a suspicious command execution on a network monitoring server. The alert shows a ping command with an appended ; cat /etc/shadow. The monitoring tool had a feature to ping IP addresses entered by users without sanitization. The attacker used this to read the password file. The correct response is to isolate the server, revoke any compromised credentials, and implement input validation (e.g., only allow valid IP addresses). The engineer should also check for other commands executed by the same attacker. A common mistake is to assume the tool is safe because it's internal, but internal tools are often targeted.

A penetration tester discovers that a login form using MongoDB is vulnerable to NoSQL injection. The tester sends a JSON payload: {"username": {"$ne": ""}, "password": {"$ne": ""}}. This returns the first user document where both fields are not empty, effectively bypassing authentication. The developer had used string interpolation to build the query. The correct remediation is to use parameterized queries (e.g., using MongoDB's $eq operator) or validate input to reject objects. The tester would report this as a critical finding. A common mistake is to think NoSQL databases are immune to injection; they are not.