injection-check

Injection Check Skill

Injection is the class of vulnerability where user-supplied input is interpreted as part of a command or query rather than as data. An agent generating database or shell code will often use string formatting because it is simpler. Simpler is what gets exploited.

What to Check Before Writing Input-Handling Code

SQL Injection Scan for string concatenation or f-string/format-string construction of SQL queries. Every parameterized query is safe. Every concatenated query is a vulnerability.

Patterns to flag:

• "SELECT * FROM users WHERE id = " + user_id
• f"SELECT * FROM users WHERE name = '{name}'"
• cursor.execute("DELETE FROM orders WHERE id = %s" % order_id) (note: %s with % substitution, not parameterized)
• Raw query builders that accept unsanitized field names for ORDER BY or column selection

Command Injection Any code that passes user input to os.system, subprocess, exec, eval, shell=True, or equivalent in any language is a block condition unless the input is fully validated against a whitelist.

Patterns to flag:

• os.system(f"convert {filename} output.pdf")
• subprocess.run(user_command, shell=True)
• eval(user_expression)

XSS (Cross-Site Scripting) HTML rendered to a browser that includes unsanitized user input is an XSS vulnerability. Flag any template or string that places user-supplied values directly into HTML without escaping. Server-side rendering frameworks that auto-escape are acceptable only if auto-escape is confirmed to be on.

LDAP Injection LDAP queries constructed from user input without escaping are injectable. Flag any LDAP filter construction that uses string concatenation with user input.

Output Format

## Injection Check

**Input sources identified:** [list of places user input enters the code]
**Query/command types constructed:** [SQL / shell / HTML / LDAP / XML / other]

### Findings
[For each finding: pattern detected, file and line, severity]

### Verdict
[CLEAR / BLOCKED — list each injection risk found]

Hard Stops

Block before writing code if:

• A SQL query is constructed via string concatenation or formatting with user input
• User input is passed to a shell command without whitelist validation
• HTML output includes user input without confirmed escaping
• eval() or exec() is called with any user-influenced value
• shell=True is used with subprocess and the command includes user input

What Good Looks Like

# Good: parameterized SQL
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

# Good: subprocess without shell, arguments as list
result = subprocess.run(["convert", filename, "output.pdf"], capture_output=True)

# Good: ORM with parameterization built in
user = User.objects.filter(id=user_id).first()

# Bad: SQL concatenation
cursor.execute("SELECT * FROM users WHERE id = " + user_id)

# Bad: shell command with user input
os.system(f"convert {request.args['file']} output.pdf")