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:

{
  "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": "test@test.com' 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.
• These are test inputs, not exploit code. Frame output as defensive testing material.
• If the code already has strong validation visible in the source, generate inputs that specifically test the validation boundaries.
• Include both inputs that should be rejected (malicious) and inputs that should be accepted (edge case valid) to test for false positives in validation.