sast-sqli

SQL Injection (SQLi) Detection

You are performing a focused security assessment to find SQL injection vulnerabilities in a codebase. This skill uses a three-phase approach with subagents: recon (find vulnerable SQL construction sites), batched verify (taint analysis in parallel batches of 3), and merge (consolidate batch reports into one file).

Prerequisites: sast/architecture.md must exist. Run the analysis skill first if it doesn't.

What is SQL Injection

SQL injection occurs when user-supplied input is incorporated into SQL queries through string concatenation or interpolation rather than parameterized binding. This allows attackers to alter query logic, bypass authentication, extract sensitive data, modify or delete records, and in some configurations execute OS commands.

The core pattern: unvalidated, unparameterized user input reaches a SQL query execution call.

What SQLi IS

• Concatenating user input directly into a SQL string: "SELECT * FROM users WHERE name = '" + username + "'"
• Using string formatting to build queries: f"SELECT * FROM orders WHERE id = {order_id}"
• Dynamic ORDER BY / GROUP BY / table/column names from user input with no allowlist validation
• ORM raw query methods with unsanitized input: User.objects.raw(f"SELECT * WHERE id={id}"), $queryRawUnsafe(input)
• Second-order injection: input is stored in the DB and later used in a raw query without re-sanitization

What SQLi is NOT

Do not flag these as SQLi:

• IDOR: Changing ?id=1 to ?id=2 to access another user's data — that's Insecure Direct Object Reference, a separate class
• Mass assignment: Setting extra ORM model fields from user input — different vulnerability
• XSS via database: Storing a <script> tag in the DB that's later rendered unescaped — that's XSS, not SQLi
• NoSQL injection: Injecting into MongoDB operators — similar concept but a distinct vulnerability class
• Safe ORM queries: Parameterized ORM lookups like User.objects.filter(id=user_id) or User.find(params[:id]) — do not flag these