SQL Injection

When user input is concatenated into a query, an attacker can rewrite the query itself — reading or destroying the database.

11 min read

SQL injection (SQLi) occurs when untrusted input is placed directly into a SQL statement. The attacker breaks out of the data context and changes the *logic* of the query.

The classic vulnerable pattern

// DANGEROUS — string concatenation
query("SELECT * FROM users WHERE name = '" + input + "'");

Send input = ' OR '1'='1 and the query becomes … WHERE name = '' OR '1'='1' — always true, returning every row.

Detecting it

A single quote ' causes a 500 or a database error → strong signal.
' AND SLEEP(5)-- - makes the response take 5s → blind / time-based SQLi, even with no visible output.
Boolean tests (' AND 1=1 vs ' AND 1=2) that change the response confirm injection.

Automate confirmation with sqlmap once you’ve found a candidate parameter — but understand the manual payloads first, or you’ll misread its output and file false positives.

Impact

Read every table (credentials, PII, tokens), bypass authentication, modify or delete data, and on some engines read/write files or get code execution. SQLi is consistently a top-paying, high-severity bug.

The only real fix

Use parameterised queries / prepared statements so input can never change query structure. ORMs help but can still be misused with raw fragments. Input validation and least-privilege DB accounts are defence-in-depth, not a substitute.

// SAFE — parameterised
query("SELECT * FROM users WHERE name = $1", [input]);