# Florianbuetow Claude Code Fuzz > Fuzz Input Generation - Skill: `tomevault-io/florianbuetow-claude-code-fuzz` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/florianbuetow-claude-code-fuzz` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/florianbuetow-claude-code-fuzz/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/florianbuetow-claude-code-fuzz --- # 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": "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. --- > Converted and distributed by [TomeVault](https://tomevault.io/claim/florianbuetow) — claim your Tome and manage your conversions.