fuzz

What this skill does

# Fuzz Input Generation

Generate intelligent, context-aware fuzz test inputs by analyzing input
parsing code. Produces boundary values, type confusion inputs, encoding
edge cases, format-specific attacks, and injection payloads tailored to the
specific parser and data types in scope. Output is structured JSON test
case sets ready for integration with test harnesses.

## Supported Flags

Read `../../shared/schemas/flags.md` for the full flag specification.

| Flag | Fuzz Behavior |
|------|-------------|
| `--scope` | Identifies which input handlers to generate fuzz inputs for. Default `changed`. |
| `--depth quick` | Standard boundary values and common injection strings only. |
| `--depth standard` | Context-aware inputs based on code analysis of the parser. |
| `--depth deep` | Standard + format-specific attacks, encoding mutations, and chained payloads. |
| `--depth expert` | Deep + adversarial inputs designed to bypass specific validation logic found in code. |
| `--severity` | Generate inputs targeting vulnerabilities at or above this severity. |
| `--format` | Default `json`. Use `text` for human-readable listing. |

## Workflow

### Step 1: Identify Input Handlers

Locate input parsing and processing code in scope:

1. **API endpoint handlers**: Functions that read request body, query params, headers.
2. **File parsers**: Functions that parse uploaded files, config files, data imports.
3. **CLI argument parsers**: Argument parsing with `argparse`, `commander`, `cobra`, `clap`.
4. **Message consumers**: Functions processing messages from queues, WebSockets, SSE.
5. **Deserialization points**: JSON.parse, XML parsing, YAML loading, protobuf decoding.
6. **Database query builders**: Functions constructing queries from user input.

For each handler, identify:
- Expected input type (string, number, array, object, file).
- Validation rules (regex, schema, type checks, length limits).
- How the input is used downstream (SQL, shell, HTML, file path, URL, regex).

### Step 2: Analyze Input Constraints

Read the code to understand what the parser expects and what it guards against:

1. **Type expectations**: What types does the code assume? Where are type coercions?
2. **Length limits**: Are there explicit length checks? What happens at max length?
3. **Character restrictions**: Are certain characters filtered or escaped? Which ones?
4. **Format requirements**: Does the input need to match a pattern (email, URL, date)?
5. **Range constraints**: Numeric bounds, enum values, allowed file extensions.
6. **Nested structure**: How deep can objects/arrays nest? Are there recursion limits?

### Step 3: Generate Boundary Value Inputs

For each input field, generate boundary value test cases:

| Input Type | Boundary Values |
|-----------|----------------|
| String | Empty `""`, single char `"a"`, max length, max length + 1, unicode BOM, null bytes `"\x00"` |
| Number | 0, -1, MAX_INT, MIN_INT, MAX_INT+1, NaN, Infinity, -Infinity, float precision edge cases |
| Array | Empty `[]`, single element, very large array (10000+), nested arrays, mixed types |
| Object | Empty `{}`, deeply nested (100+ levels), circular reference attempt, prototype keys |
| Boolean | `true`, `false`, `0`, `1`, `""`, `"false"`, `null`, `undefined` |
| Date | Epoch 0, negative timestamp, far future, invalid dates (Feb 30), timezone edge cases |
| File | Empty file, 0-byte, huge file, wrong extension, polyglot file, symlink |

### Step 4: Generate Type Confusion Inputs

Inputs designed to exploit type coercion and type assumption bugs:

Generate inputs that send the wrong type: string where number expected, array where string expected, object with `toString` override, deeply nested arrays, null where required, boolean where string expected, numeric string where number expected, and prototype/constructor pollution objects (`__proto__`, `constructor.prototype`).

### Step 5: Generate Encoding Edge Cases

Inputs exploiting encoding and character set handling:

1. **Unicode**: Normalization forms (NFC, NFD, NFKC, NFKD), homoglyphs, right-to-left override, zero-width characters.
2. **URL encoding**: Double encoding (`%2527`), mixed encoding, overlong UTF-8.
3. **HTML entities**: Named (`&`), numeric (`&`), hex (`&`), surrogate pairs.
4. **Null bytes**: Mid-string null bytes for truncation attacks.
5. **Line endings**: `\r\n`, `\r`, `\n`, `\x0b`, `\x0c`, `\x85`, `\u2028`, `\u2029`.
6. **Case mapping**: Turkish locale `I`/`i` dotless variants, German `ß`/`SS`.

### Step 6: Generate Context-Aware Injection Payloads

Based on how the input is used downstream (identified in Step 1), generate targeted payloads:

| Sink Context | Payload Category |
|-------------|-----------------|
| SQL query | SQL injection: UNION, boolean blind, time blind, stacked queries, comment-based |
| Shell command | Command injection: semicolons, pipes, backticks, `$()`, newlines |
| HTML output | XSS: script tags, event handlers, SVG/MathML, template injection |
| File path | Path traversal: `../`, null bytes, long paths, reserved names (CON, NUL) |
| URL construction | SSRF: localhost variants, IPv6, DNS rebinding, scheme confusion |
| Regex input | ReDoS: catastrophic backtracking patterns, exponential quantifiers |
| XML parser | XXE: external entity, parameter entity, SSRF via DTD |
| LDAP query | LDAP injection: wildcards, boolean operators, null bytes |
| Header value | Header injection: CRLF, response splitting |
| JSON parser | JSON interoperability: duplicate keys, large numbers, deep nesting |

### Step 7: Generate Format-Specific Attacks

At `--depth deep` and above, generate inputs targeting specific file/data formats:

1. **JSON**: Duplicate keys (parser-dependent behavior), comments, trailing commas, BOM prefix.
2. **XML**: Billion laughs, quadratic blowup, external entities, CDATA abuse.
3. **YAML**: Anchor bombs, merge keys, tag deserialization (`!!python/object`).
4. **CSV**: Formula injection (`=CMD()`), field separator in values, newlines in quoted fields.
5. **JWT**: Algorithm none, key confusion (RS256/HS256), expired but valid signature.
6. **GraphQL**: Deep nesting, alias flooding, batch query abuse, introspection.
7. **Multipart**: Boundary manipulation, filename traversal, content-type mismatch.

### Step 8: Output Test Case Sets

Organize all generated inputs into structured JSON test case sets:

```json
{
  "target": {
    "file": "src/api/users.ts",
    "function": "createUser",
    "input_field": "email",
    "expected_type": "string",
    "downstream_use": ["sql_query", "html_email"]
  },
  "generated_at": "2026-02-14T10:30:00Z",
  "total_cases": 85,
  "test_cases": [
    {
      "id": "FUZZ-001",
      "category": "boundary",
      "label": "empty_string",
      "input": "",
      "expected_behavior": "validation_error",
      "targets_cwe": "CWE-20"
    },
    {
      "id": "FUZZ-002",
      "category": "injection_sql",
      "label": "union_select",
      "input": "[email protected]' UNION SELECT * FROM users--",
      "expected_behavior": "parameterized_query_prevents_injection",
      "targets_cwe": "CWE-89"
    }
  ]
}
```

Write test case files to `.appsec/fuzz/` organized by target.

## Output Format

Fuzz inputs are not findings themselves but may reference CWEs they target.

Finding ID prefix: **FUZZ** (e.g., `FUZZ-001`) for test case identification.

- `metadata.tool`: `"fuzz"`

If fuzz testing reveals an actual vulnerability (input causes unexpected behavior), emit a finding using `../../shared/schemas/findings.md`.

## Pragmatism Notes

- Generate inputs relevant to the actual technology. Do not generate SQL injection payloads for code that never touches a database.
- Respect the `--depth` flag. Quick depth should produce 10-20 inputs. Expert depth can produce hundreds.
- Label each input clearly so testers understand what it targets and what behavior to expect.
- Mark intentionally dangerous inputs (e.g., billion laughs XML) with a warning about resource consumption.
-