Injection Attacks

Injection attacks occur when an attacker sends untrusted data to an interpreter as part of a command or query. The interpreter executes the malicious input, allowing the attacker to access data, modify records, or execute system commands. Injection has been one of the most dangerous web application vulnerabilities for over two decades.

---

How Injection Works

The fundamental cause of injection is mixing code with data. When user input is concatenated directly into a command or query without proper handling, the interpreter cannot distinguish between the intended command and the attacker's input.

Trusted Command + Untrusted User Input = Potentially Malicious Command

---

Types of Injection Attacks

Type	Target Interpreter	Example
SQL Injection	SQL database engine	Manipulating database queries
NoSQL Injection	NoSQL databases (MongoDB, etc.)	Modifying NoSQL query operators
OS Command Injection	Operating system shell	Executing system commands
LDAP Injection	LDAP directory services	Modifying directory queries
XPath Injection	XML parsers	Manipulating XML queries
ORM Injection	Object-Relational Mappers	Bypassing ORM protections
Header Injection	HTTP headers	Injecting malicious headers (CRLF injection)
Template Injection	Server-side template engines	Executing arbitrary code via templates (SSTI)

---

SQL Injection — The Classic Attack

SQL injection (SQLi) is the most well-known and widespread injection vulnerability.

How It Works

Consider a login form that constructs a query by concatenating user input:

# VULNERABLE CODE — never do this
query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'"

If an attacker enters ' OR '1'='1' -- as the username:

SELECT * FROM users WHERE username = '' OR '1'='1' --' AND password = 'anything'

The -- comments out the rest of the query. Since '1'='1' is always true, the query returns all users, and the attacker is logged in as the first user (often the administrator).

Types of SQL Injection

Type	Description	Detection
In-band (Classic)	Results returned directly in the application response	Error messages or different page content
Error-based	Database error messages reveal information	Verbose error output
UNION-based	UNION SELECT used to retrieve data from other tables	Data from other tables in the response
Blind (Boolean-based)	No visible output; attacker infers data from true/false responses	Conditional differences in responses
Blind (Time-based)	No visible output; attacker uses time delays to infer data	Response time variations
Out-of-band	Data exfiltrated through a separate channel (DNS, HTTP)	External server receives data

SQL Injection Prevention

1. Parameterised Queries (Prepared Statements)

The most effective defence — separate code from data:

# Python with psycopg2
cursor.execute("SELECT * FROM users WHERE username = %s AND password = %s", (username, password))

// Java with PreparedStatement
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE username = ? AND password = ?");
stmt.setString(1, username);
stmt.setString(2, password);

// Node.js with parameterised query
const result = await pool.query('SELECT * FROM users WHERE username = $1 AND password = $2', [username, password]);

2. Use an ORM

ORMs like Prisma, Sequelize, SQLAlchemy, or Hibernate automatically parameterise queries:

// Prisma — automatically safe from SQL injection
const user = await prisma.user.findFirst({
  where: { username: input.username, password: hashedPassword },
});

3. Input Validation

Validate that inputs match expected patterns: