Marcos Silva
86 lines
2.4 KiB
Markdown
86 lines
2.4 KiB
Markdown
---
|
|
name: sql-injection-audit
|
|
description: Check repository code for SQL injection vulnerabilities. Use when creating, modifying, reviewing, or debugging code that builds or executes SQL queries.
|
|
SQL Injection Audit
|
|
---
|
|
|
|
# SQL Injection analysis
|
|
|
|
Use this skill when working with code that interacts with relational databases or constructs SQL queries.
|
|
|
|
## Core Rules
|
|
|
|
- Treat all external/user-controlled input as untrusted.
|
|
- Never concatenate or interpolate untrusted input directly into SQL.
|
|
- Prefer parameterized queries or prepared statements.
|
|
- Use ORM/query-builder parameterization when available.
|
|
- Do not rely on input sanitization or escaping as the primary defense.
|
|
- Review raw SQL and ORM escape-hatch APIs carefully.
|
|
- Validate dynamic SQL identifiers such as table names and column names with strict allowlists.
|
|
- Consider second-order SQL injection when user-controlled data is stored and later used in SQL.
|
|
- Do not consider tests passing as proof that SQL injection is impossible.
|
|
|
|
## Review Workflow
|
|
|
|
1. Identify SQL execution points:
|
|
|
|
- raw SQL;
|
|
- database driver queries;
|
|
- ORM raw queries;
|
|
- query builders;
|
|
- stored procedures;
|
|
- dynamically generated SQL.
|
|
|
|
2. Trace untrusted input into SQL:
|
|
|
|
- HTTP parameters;
|
|
- request bodies;
|
|
- headers;
|
|
- cookies;
|
|
- GraphQL inputs;
|
|
- CLI arguments;
|
|
- external API data;
|
|
- stored user-controlled data.
|
|
|
|
3. Look for dangerous patterns:
|
|
|
|
- string concatenation;
|
|
- template literals;
|
|
- dynamic WHERE clauses;
|
|
- dynamic ORDER BY;
|
|
- dynamic table/column names;
|
|
- raw SQL fragments;
|
|
- unsafe ORM APIs.
|
|
|
|
4. Verify the fix:
|
|
|
|
- confirm values are passed as SQL parameters;
|
|
- confirm dynamic identifiers use an allowlist;
|
|
- review relevant tests;
|
|
- run existing security/static-analysis tools when available.
|
|
|
|
5. Report findings with:
|
|
|
|
- severity;
|
|
- file and line;
|
|
- source of untrusted input;
|
|
- SQL sink;
|
|
- data flow;
|
|
- impact;
|
|
- recommended fix.
|
|
- Secure Pattern
|
|
|
|
|
|
## Completion Criteria
|
|
|
|
Before completing the task:
|
|
|
|
- Relevant SQL queries were reviewed.
|
|
- Untrusted input flows were checked.
|
|
- Raw SQL and ORM escape hatches were reviewed.
|
|
- Parameterization was verified.
|
|
- Dynamic identifiers were checked.
|
|
- Relevant tests were reviewed or run.
|
|
- Any SQL injection risk is explicitly reported.
|
|
|
|
If the requested change introduces SQL injection, stop and explain the vulnerability and recommend a parameterized or otherwise safe implementation. |