injection

What this skill does

# Injection Analysis (OWASP A03:2021)

Analyze source code for injection vulnerabilities where user-supplied data flows
into interpreters without proper validation, sanitization, or parameterization.
This is the most code-scannable OWASP category -- most injection patterns leave
clear syntactic fingerprints in source code.

## Supported Flags

Read `../../shared/schemas/flags.md` for the full flag specification. This skill
supports all cross-cutting flags. Key behaviors:

| Flag | Injection-Specific Behavior |
|------|-----------------------------|
| `--scope` | Default `changed`. Injection analysis focuses on files containing database queries, system calls, LDAP operations, and eval constructs. |
| `--depth quick` | Scanners + Grep patterns only, no data-flow tracing. |
| `--depth standard` | Full code read of scoped files, local data-flow analysis within each file. |
| `--depth deep` | Trace user input from HTTP entry points through call chains to sinks. Cross-file taint analysis. |
| `--depth expert` | Deep + red team simulation: craft proof-of-concept payloads, DREAD scoring. |
| `--severity` | Filter output. Injection findings are typically `critical` or `high`. |
| `--fix` | Generate parameterized replacements for each finding. |

## Framework Context

**OWASP A03:2021 - Injection**

User-supplied data is not validated, filtered, or sanitized by the application.
Dynamic queries or commands are constructed using string concatenation or
interpolation with hostile data. Common injection types:

- **SQL Injection** (CWE-89): Unsanitized input in SQL queries
- **NoSQL Injection** (CWE-943): Unsanitized input in MongoDB/NoSQL queries
- **OS Command Injection** (CWE-78): User input passed to system shell commands
- **LDAP Injection** (CWE-90): Unsanitized input in LDAP queries
- **Expression Language Injection** (CWE-917): User input in EL/template engines
- **ORM Injection** (CWE-89): Raw queries or unsafe ORM usage with user input

**STRIDE Mapping**: Tampering, Information Disclosure, Elevation of Privilege

## Detection Patterns

Read `references/detection-patterns.md` for the full pattern catalog with
language-specific examples, regex heuristics, and false positive guidance.

**Pattern Summary**:
1. String concatenation in SQL queries
2. Template string / f-string SQL construction
3. Raw ORM queries with user input
4. `os.system` / `exec` / `subprocess` with user input
5. `eval()` / `Function()` with user input
6. LDAP query string construction with user input

## Workflow

### Step 1: Determine Scope

1. Parse `--scope` flag (default: `changed`).
2. Resolve to a concrete file list.
3. Filter to relevant file types: `.py`, `.js`, `.ts`, `.jsx`, `.tsx`, `.java`,
   `.go`, `.rb`, `.php`, `.cs`, `.rs`, `.kt`, `.scala`, `.sql`, `.graphql`.
4. Prioritize files containing: database query patterns, HTTP handler functions,
   system call imports, LDAP library usage, eval/exec constructs.

### Step 2: Check for Scanners

Detect available scanners in priority order:

| Scanner | Detect | Injection Coverage |
|---------|--------|--------------------|
| semgrep | `which semgrep` | SQL, NoSQL, OS command, LDAP, EL, ORM -- broadest coverage |
| bandit | `which bandit` | Python: eval, exec, SQL, subprocess, pickle |
| gosec | `which gosec` | Go: SQL injection, command injection |
| brakeman | `which brakeman` | Rails: SQL injection, command injection, mass assignment |
| spotbugs | Maven/Gradle plugin | Java: SQL injection, command injection, XXE, LDAP |

Record which scanners are available and which are missing. If none are available,
note: "No scanner available -- findings based on code pattern analysis only."

### Step 3: Run Scanners

For each available scanner, run against the scoped files:

```
semgrep scan --config auto --json --quiet <target>
bandit -r <target> -f json -q
gosec -fmt json ./...
```

Normalize scanner output to the findings schema (see `../../shared/schemas/findings.md`).
Use the severity mapping from `../../shared/schemas/scanners.md`.

### Step 4: Claude Analysis

Read each scoped file and analyze for injection patterns not caught by scanners:

1. **Identify sinks**: Database query functions, system calls, LDAP operations,
   eval/exec, template engines.
2. **Trace sources**: HTTP request parameters, form data, URL path segments,
   headers, cookies, file uploads, environment variables from user input.
3. **Check sanitization**: Is there parameterization, input validation,
   allowlisting, or escaping between source and sink?
4. **Assess context**: Is the code reachable from an external entry point?
   Is there framework-level protection (e.g., Django ORM, prepared statements)?
5. **Deduplicate**: Merge Claude findings with scanner findings. If both found
   the same issue, keep the scanner finding and add Claude's context.

At `--depth deep` or `--depth expert`, trace data flow across files:
- Follow function calls from HTTP handlers to database/system call sites.
- Check middleware and interceptors for global sanitization.
- Map the full taint path: source -> transforms -> sink.

### Step 5: Report

Output findings using the format from `../../shared/schemas/findings.md`.

Each finding must include:
- **id**: `INJ-001`, `INJ-002`, etc.
- **title**: Concise description of the injection type and location.
- **severity**: Based on exploitability, authentication requirements, and impact.
- **location**: File, line, function, and vulnerable code snippet.
- **description**: What is vulnerable and why.
- **impact**: What an attacker can achieve.
- **fix**: Parameterized/safe replacement code.
- **references**: CWE, OWASP A03:2021, STRIDE mapping.

## What to Look For

These are the primary injection patterns to detect. Each has detailed examples
and regex heuristics in `references/detection-patterns.md`.

1. **String concatenation in SQL**: `"SELECT * FROM users WHERE id = " + userId`
2. **Template literals in SQL**: `` `SELECT * FROM users WHERE id = ${userId}` ``
3. **F-strings / format strings in SQL**: `f"SELECT * FROM users WHERE id = {user_id}"`
4. **Raw ORM queries**: `Model.objects.raw(user_input)`, `sequelize.query(userInput)`
5. **OS command construction**: `os.system("ping " + host)`, `exec("ls " + dir)`
6. **subprocess with shell=True**: `subprocess.call(cmd, shell=True)` where `cmd` includes user input
7. **eval/exec with user input**: `eval(request.body)`, `new Function(userCode)()`
8. **LDAP filter construction**: `"(uid=" + username + ")"` without escaping
9. **NoSQL operator injection**: `db.users.find({username: req.body.username})` where body can contain `$gt`, `$ne`
10. **Stored procedures with concatenation**: Dynamic SQL inside stored procedures

## Scanner Integration

**Primary**: semgrep (broadest injection coverage across languages)
**Language-specific**: bandit (Python), gosec (Go), brakeman (Rails), spotbugs (Java)
**Fallback**: Grep regex patterns from `references/detection-patterns.md`

When scanners are available, run them first and use Claude analysis to:
- Validate scanner findings (reduce false positives).
- Find injection patterns scanners miss (complex data flows, indirect concatenation).
- Provide fix suggestions with parameterized replacements.

When no scanners are available, Claude performs full pattern-based analysis using
the Grep heuristics from `references/detection-patterns.md` and contextual code
reading. Report these findings with `confidence: medium`.

## Output Format

Use finding ID prefix **INJ** (e.g., `INJ-001`, `INJ-002`).

All findings follow the schema in `../../shared/schemas/findings.md` with:
- `references.owasp`: `"A03:2021"`
- `references.stride`: `"T"` (Tampering), `"I"` (Info Disclosure), or `"E"` (Elevation of Privilege)
- `metadata.tool`: `"injection"`
- `metadata.framework`: `"owasp"`
- `metadata.category`: `"A03"`

**CWE Mapping by Injection Type**:

| Injection Type | CWE | Typical Severity |
|---------------|-----|-----------------|
| SQL Injection | CWE-89 | critical |