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:
- Discovery: Find all form inputs on the page
- Classification: Identify input types (text, email, password, search, etc.)
- Injection: For each input, try payloads from selected category
- 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)
- 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 | 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
- Start with
--fuzz-category xss: Most common web vulnerability - Test staging, not production: Fuzzing can cause side effects
- Combine with
--record: Capture evidence of vulnerabilities - Use
--jsonfor CI/CD: Parse fuzz results programmatically - Test authenticated flows: Many vulnerabilities behind login
Limitations
- Client-side only: Cannot detect server-side-only vulnerabilities
- No blind injection: Time-based SQLi detection is limited
- May trigger WAF: Fuzzing payloads can trigger security rules
- State changes: Fuzzing may create test data in database
- 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 |