feat: add submitted skills review desk
This commit is contained in:
@@ -0,0 +1,86 @@
|
||||
---
|
||||
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.
|
||||
Reference in New Issue
Block a user