SQL Injection

SQL Injection (SQLi) occurs when user-supplied data is embedded directly into a SQL query without sanitization. An attacker can break out of the intended query and execute arbitrary SQL, leading to data theft, authentication bypass, or full database compromise.

Vulnerable example (Python):

username = request.form['username']
query = "SELECT * FROM users WHERE username = '" + username + "'"
cursor.execute(query)

If the attacker sends ' OR '1'='1 as the username, the query becomes WHERE username = '' OR '1'='1', returning all rows and bypassing login.

The definitive fix is to use parameterized queries (also called prepared statements). The SQL template is compiled first; user data is passed separately and can never alter the query structure.

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

// Safe — Java JDBC
PreparedStatement stmt = conn.prepareStatement(
    "SELECT * FROM users WHERE username = ?"
);
stmt.setString(1, username);

ORMs like SQLAlchemy, Hibernate, and ActiveRecord use parameterization by default when you use their query builder — but raw string interpolation bypasses those protections.

Second-order injection happens when data is safely stored but later used unsafely in a query. Always parameterize on read, not just on write.

Blind injection is when the attacker gets no direct output but can infer data from timing differences or conditional behavior (e.g., SLEEP(5) if condition is true). Parameterized queries prevent this too.

Defense checklist:

• Use parameterized queries / prepared statements everywhere
• Apply least-privilege DB accounts (read-only where possible)
• Enable WAF rules for SQLi patterns
• Use SAST tools to flag string concatenation in SQL contexts