ncklrs/skills/form-fuzzer

Form Fuzzer Skill

Test form inputs with edge case payloads to find security vulnerabilities and encoding issues.

When to Use

• Security testing forms for XSS/SQLi vulnerabilities
• Testing input validation and sanitization
• Finding unicode/encoding handling issues
• Checking length limit enforcement
• Pre-deployment security checks

Flags

--fuzz                           Enable fuzzing mode
--fuzz-category <category>       Category: xss | sqli | unicode | length | all (default: all)

Fuzzing Categories

| Category | Purpose | Payload Count | |----------|---------|---------------| | xss | Test XSS sanitization | 15 payloads | | sqli | Test SQL injection prevention | 12 payloads | | unicode | Test encoding handling | 10 payloads | | length | Test length limits | 4 payloads | | all | All categories combined | 41 payloads |

Behavior

When --fuzz is active:

1. Discovery: Find all form inputs on the page
2. Classification: Identify input types (text, email, password, search, etc.)
3. Injection: For each input, try payloads from selected category
4. Observation: Check response for each payload:
   • Sanitized: Payload escaped/stripped (PASS)
   • Rejected: Clear error message (PASS)
   • Executed: XSS/SQLi worked (CRITICAL)
   • Error: Application error/crash (MAJOR)
   • Stored: Payload persists in DOM (CRITICAL)
5. Reporting: Generate security-focused report section

Response Classification

XSS Detection

// Check if script executed
// Check if payload appears unescaped in DOM
// Check for alert/console activity
// Check if event handlers fire

SQL Injection Detection

// Check for database error messages
// Check for unusual response time (time-based)
// Check for data leakage
// Check for error 500 responses

Encoding Issues

// Check for garbled text
// Check for broken layout (RTL markers)
// Check for missing characters
// Check for incorrect rendering

Length Handling

// Check if input truncated
// Check for overflow errors
// Check for client-side crashes
// Check for server errors

Report Section

When fuzzing is enabled, add this section to the test report:

## Form Fuzz Testing Results

### Summary
- **Inputs Tested**: 5
- **Payloads Tried**: 205
- **Vulnerabilities Found**: 2

### Critical Findings

| Input | Category | Payload | Result |
|-------|----------|---------|--------|
| #name | XSS | `<script>alert(1)</script>` | Executed |
| #search | SQLi | `' OR '1'='1` | Error 500 |

### XSS Tests (3 inputs)

| Input | Sample Payload | Result |
|-------|----------------|--------|
| #email | `<script>alert(1)</script>` | Sanitized |
| #name | `<script>alert(1)</script>` | **Executed** |
| #bio | `<img onerror=alert(1)>` | Sanitized |

### SQL Injection Tests (2 inputs)

| Input | Sample Payload | Result |
|-------|----------------|--------|
| #search | `' OR '1'='1` | **Error 500** |
| #id | `1; DROP TABLE--` | Rejected |

### Unicode Tests (5 inputs)

| Input | Sample Payload | Result |
|-------|----------------|--------|
| #name | `cafe n beijing` | Rendered OK |
| #bio | RTL markers | Layout OK |

### Length Tests (3 inputs)

| Input | Length | Result |
|-------|--------|--------|
| #email | 1K chars | Truncated (OK) |
| #bio | 10K chars | Accepted |
| #bio | 100K chars | **Client crash** |

### Recommendations

1. **[Critical]** Sanitize `#name` field - XSS vulnerable
2. **[Critical]** Fix SQL error handling in `#search` - reveals database info
3. **[Major]** Add length validation to `#bio` - crashes on large input

Integration with Personas

Fuzzing works alongside persona testing:

# Fuzz while testing as GenZ user
/user-test --url https://example.com/signup --persona genz-digital-native --fuzz

# Fuzz specific category
/user-test --url https://example.com/login --persona developer-critic --fuzz --fuzz-category xss

The persona still drives navigation and task completion, but form inputs are fuzzed when encountered.

Input Selection

Fuzz These Inputs

• <input type="text">
• <input type="email">
• <input type="password">
• <input type="search">
• <input type="url">
• <input type="tel">
• <textarea>
• <input type="hidden"> (if accessible)
• Rich text editors (contenteditable)

Skip These Inputs

• <input type="checkbox">
• <input type="radio">
• <input type="file">
• <input type="date/time">
• <select> dropdowns
• Disabled/readonly inputs

Best Practices

1. Start with --fuzz-category xss: Most common web vulnerability
2. Test staging, not production: Fuzzing can cause side effects
3. Combine with --record: Capture evidence of vulnerabilities
4. Use --json for CI/CD: Parse fuzz results programmatically
5. Test authenticated flows: Many vulnerabilities behind login

Limitations

1. Client-side only: Cannot detect server-side-only vulnerabilities
2. No blind injection: Time-based SQLi detection is limited
3. May trigger WAF: Fuzzing payloads can trigger security rules
4. State changes: Fuzzing may create test data in database
5. Rate limiting: May hit rate limits on aggressive testing

Severity Classification

| Severity | Criteria | Example | |----------|----------|---------| | Critical | Code execution, data exposure | XSS executed, SQLi data leak | | Major | Application errors, crashes | Error 500, client crash | | Minor | Poor handling, no security impact | Garbled unicode, no truncation | | Info | Observations, potential issues | Long response time, verbose errors |