Web Application Fuzzing Automation
by @quochungto
Build and execute customized automated attacks against web applications. Use this skill when: systematically enumerating valid identifiers (userids, document...
clawhub install bookforge-web-application-fuzzing-automationπ About This Skill
name: web-application-fuzzing-automation description: | Build and execute customized automated attacks against web applications. Use this skill when: systematically enumerating valid identifiers (userids, document IDs, session tokens) by iterating through a parameter range and detecting hits via HTTP status code, response length, response time, Location header, Set-Cookie header, or grep expression; harvesting sensitive data at scale from access-control-flawed endpoints; fuzzing every request parameter with a universal payload kit covering SQL injection (
', '--, '; waitfor delay '0:30:0'--), XSS (xsstest, ">), OS command injection (|| ping -i 30 127.0.0.1 ; x || ping -n 30 127.0.0.1 & and separator variants), path traversal (../../../../../../etc/passwd, ../../../../../../boot.ini), script injection (;echo 111111, response.write 111111), and remote file inclusion (http:/// ); selecting the correct Burp Intruder attack type: Sniper (one position cycled through all payloads), Battering Ram (same payload into all positions simultaneously), Pitchfork (parallel payload sets, one per position, advanced in lockstep), or Cluster Bomb (Cartesian product of multiple payload sets across multiple positions); maintaining valid sessions across automated runs using Burp Suite cookie jar, request macros (login, token fetch, multistep pre-requests), and session-handling rules (check session validity, run re-login macro, update token per request); bypassing automation barriers including per-request anti-CSRF tokens (macro extracts token from prior response, session-handling rule injects it), session expiry (validate-and-re-login rule), and CAPTCHA (solution exposed in source, solution replay, OCR, or human-solver integration); triaging results by clicking column headings to sort by status/length/time and Shift-clicking to reverse-sort. Covers JAttack custom Java scripting framework as a reference model for payload source design and response parsing. For authorized penetration testing and application security assessment only.
version: 1.0.0
homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/web-application-hackers-handbook/skills/web-application-fuzzing-automation
metadata: {"openclaw":{"emoji":"π","homepage":"https://github.com/bookforge-ai/bookforge-skills"}}
status: draft
depends-on: []
source-books:
- id: web-application-hackers-handbook
title: "The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws"
authors: ["Dafydd Stuttard", "Marcus Pinto"]
edition: 2
chapters: [14]
pages: "571-613"
tags: [fuzzing, burp-intruder, automation, identifier-enumeration, data-harvesting, sql-injection, xss, os-command-injection, path-traversal, session-handling, csrf-token, captcha-bypass, payload-generation, penetration-testing, appsec]
execution:
tier: 2
mode: interactive
inputs:
- type: document
description: "HTTP traffic / Burp Suite project file β request/response pairs to target"
- type: text
description: "Target URL, parameter names, scope confirmation from authorizing party"
tools-required: [Read, Write]
tools-optional: [Bash, WebFetch]
mcps-required: []
environment: "Authorized penetration test engagement. Burp Suite Professional (or equivalent) required for Intruder attack types and session-handling features. JAttack source available at companion site for custom scripting."
discovery:
goal: "Enumerate valid identifiers, harvest data from vulnerable endpoints, or identify input-based vulnerabilities across all request parameters via automated fuzzing β producing a triage-ready results table and prioritized follow-up list"
tasks:
- "Select the correct automation mode (enumeration, harvesting, or fuzzing) and configure the matching attack type and payload source"
- "Configure hit detection criteria appropriate to the target's response behavior"
- "Address session-handling barriers before launching to prevent false negatives from expired sessions or missing tokens"
- "Launch the attack, triage results by sorting on status/length/time/grep columns, and escalate anomalies to manual verification"
audience:
roles: ["penetration-tester", "application-security-engineer", "bug-bounty-researcher"]
experience: "intermediate-to-advanced β assumes working knowledge of HTTP, Burp Suite proxy/Intruder, and web vulnerability classes"
triggers:
- "Authorized pentest of an application with predictable identifiers, access-control findings worth harvesting, or large parameter surface needing fuzzing"
- "Coverage of dozens of dynamic pages where manual per-parameter testing is not feasible"
- "Session token analysis has revealed a pattern amenable to enumeration"
- "Burp Scanner found a potential injection but coverage of remaining parameters is needed"
not_for:
- "Unauthenticated or unauthorized testing β written authorization required"
- "Fully automated scanning without human triage β customized automation surpasses scanners only when a human reviews results"
- "Deep exploitation of confirmed vulnerabilities β use dedicated exploit skills after fuzzing identifies the candidate"
Web Application Fuzzing Automation
When to Use
You have authorized access to a web application and need to go beyond manual, one-request-at-a-time testing. Customized automation is appropriate when:
The core insight: Every web application is different. Off-the-shelf scanners apply generic signatures. A skilled tester using customized automation combines human intelligence (selecting the right request, interpreting subtle response differences, thinking like the application's designer) with computerized brute force to achieve results neither can deliver alone.
Authorized testing only. Never apply these techniques without explicit written authorization from the application owner.
Context and Input Gathering
Required Context
Observable Context (gather from environment)
uid=198, docId=10069, pageid=32010039__csrftoken, nonce, _token), session expiry behavior, multistage processesProcess
Step 1: Choose the Automation Mode
Three distinct uses for customized automation, each requiring different configuration:
Identifier Enumeration β Iterate through a range of values for a single parameter to determine which are valid. Hit detection is binary (valid vs. invalid). Payload source: numeric range or custom list.
Data Harvesting β Extend enumeration to extract content from each hit (page titles, names, credentials). Requires adding Extract Grep patterns to pull specific strings from each response. Hit detection is still used but you also capture response content.
Vulnerability Fuzzing β Submit a universal set of attack strings to every parameter in every request, regardless of normal function. You do not know in advance what a hit looks like; you capture as much response detail as possible and review manually for anomalies.
WHY distinct modes matter: Enumeration and harvesting require a focused request with a known-good baseline. Fuzzing is deliberately broad β you sacrifice focus for coverage. Mixing the two produces poor results: fuzzing an already-exploited endpoint wastes requests; applying a focused enumeration payload to a fuzz target misses everything else.
Step 2: Configure Attack Type (Burp Intruder)
Select the attack type based on how many payload positions and payload sets your attack requires:
| Attack Type | Positions | Payload Sets | Behavior | Best For | |---|---|---|---|---| | Sniper | One at a time | 1 | Cycles each position through all payloads; other positions hold their baseline value | Fuzzing each parameter independently; most common choice | | Battering Ram | All simultaneously | 1 | Same payload inserted into every position at once | Testing username-equals-password login, or inserting a single attack string everywhere | | Pitchfork | Multiple, in lockstep | One per position | Advances all payload lists simultaneously (position 1 gets payload 1 from list A, position 2 gets payload 1 from list B, etc.) | Testing credential pairs from a known username/password list | | Cluster Bomb | Multiple | One per position | Cartesian product β every combination of all payload sets | Brute-forcing debug parameter name + value pairs; credential stuffing from independent lists |
WHY Sniper is the default for fuzzing: When fuzzing for input-based vulnerabilities, you need to test each parameter in isolation. If you inject into all parameters simultaneously, an anomalous response becomes ambiguous β you cannot determine which payload in which parameter triggered it. Sniper eliminates this ambiguity. Each payload appears in exactly one parameter per request; all others remain at their baseline values.
Set payload positions: Use the "Auto" button in Intruder's Positions tab to mark all URL, cookie, and body parameter values automatically. Manually adjust to add or remove positions as needed.
Step 3: Configure Payload Source
For enumeration/harvesting: Use the Numbers payload type. Configure sequential hexadecimal or decimal range, step size, and minimum digit count to match the application's identifier format. Example: tokens ending in 3 hex digits β range 0x000 to 0xfff, hex format, minimum 3 digits.
For fuzzing: Use the universal payload kit below. These are literal strings β Burp URL-encodes special characters by default; do not disable this.
# SQL Injection
'
'--
'; waitfor delay '0:30:0'--
1; waitfor delay '0:30:0'--XSS and Header Injection
xsstest
">OS Command Injection
|| ping -i 30 127.0.0.1 ; x || ping -n 30 127.0.0.1 &
| ping -i 30 127.0.0.1 |
| ping -n 30 127.0.0.1 |
& ping -i 30 127.0.0.1 &
& ping -n 30 127.0.0.1 &
; ping 127.0.0.1 ;
%0a ping -i 30 127.0.0.1 %0a
ping 127.0.0.1 Path Traversal
../../../../../../../../../../etc/passwd
../../../../../../../../../../boot.ini
..\..\..\..\..\..\..\..\..\..\etc\passwd
..\..\..\..\..\..\..\..\..\..\boot.iniScript Injection
;echo 111111
echo 111111
response.write 111111
;response.write 111111File Inclusion (point at a server you control and monitor for incoming connections)
http:///
http:///
WHY this kit: Each string is the minimal probe for its class. The SQL ' triggers syntax errors. The waitfor variants detect blind time-based SQL injection. The OS command strings use ping with a controlled delay β a 30-second response confirms blind injection regardless of whether output is visible. Script injection uses the literal value 111111 β if it appears alone in the response, the input was executed. Path traversal strings use redundant ../ sequences so they work regardless of how deep the web root is. File inclusion strings require monitoring for out-of-band connections, not response content.
Step 4: Configure Hit Detection and Response Analysis
In Burp Intruder's Options tab, configure the attributes to capture from each response:
Baseline columns (always captured):
Grep β Match: Configure strings to flag in responses. For fuzzing, use:
error
exception
illegal
invalid
fail
stack
access
directory
file
not found
varchar
ODBC
SQL
SELECT
111111
quotation
syntax
Grep β Extract: For data harvesting, configure strings that precede the data you want to capture. Example: Grep β Payload: Enable "flag responses that reflect the payload" to detect potential XSS β any response that echoes back the WHY response length is critical even when you have a reliable status code indicator: Response length frequently surfaces anomalies you did not anticipate when designing the attack. In a session token enumeration, all HTTP 200 hits return roughly the same page β but noticeably longer responses indicate more-privileged user sessions. Always sort length even when status provides the primary signal. Identify which barriers apply to the target, then configure Burp's session-handling stack in the order below. Each layer operates on every outgoing Intruder request automatically. Cookie Jar (always enable):
Burp maintains a cookie jar tracking all application cookies seen in proxied traffic. Enable "add cookies from cookie jar" as the first session-handling rule action for the target domain. This ensures the most recent session token is always included. Request Macros:
A macro is a predefined sequence of one or more requests replayed before (or instead of) the attack request. Define macros for each barrier: Session-Handling Rules (apply in this order): 1. All requests to target domain: Add cookies from cookie jar.
2. All requests to target domain: Check whether session is valid by running the validate-session macro. If session is invalid, run the re-login macro and update the cookie jar.
3. Requests containing the anti-CSRF token parameter: Run the obtain-token macro and set the token parameter to the extracted value from the macro's final response. Scope each rule to the correct Burp tools (Spider, Scanner, Intruder, Repeater as appropriate) and to the target host/URL pattern. Use the session-handling tracer to verify each rule fires correctly before launching the full attack. WHY this ordering matters: Adding the cookie jar before the session-validity check ensures the check uses the current token, not a stale one. Validating before every request (rather than on failure) prevents a wave of failed requests from triggering account lockout or defensive session termination. Obtaining the token last ensures it is always fresh β anti-CSRF tokens are typically invalidated after a single use. Launch the attack in Burp Intruder. Results appear in a table with one row per request. Triage workflow: 1. Click the Status column heading to sort by HTTP status code. Anomalous status codes (200 among mostly 302, or 500 among mostly 200) surface immediately.
2. Click the Length column heading to sort by response length. Responses that are meaningfully longer or shorter than the majority are candidates for further review.
3. Click the Time column heading to sort by response time. Significant delays (β₯25 seconds) against OS command injection payloads confirm blind time-based injection.
4. Click each Grep column heading to surface responses that matched the error/exception strings.
5. Shift-click any column to reverse-sort β useful to move both extremes into view without re-sorting by hand.
6. Double-click any row to view the full request and response. Right-click and "Send to Repeater" to manually investigate and refine the finding. What to look for: For each confirmed or suspected finding, refer to the dedicated vulnerability skill for detailed exploitation and verification steps. Attack Results Table with one row per request, columns: request number, parameter, payload, HTTP status, response length, response time, grep matches, extracted data (if configured). Sorted to surface anomalies. Follow-up Findings List β for each anomalous row:
Scenario: Session token enumeration on an application with weak token generation Trigger: "The session tokens look partially sequential β I want to enumerate valid sessions for privilege escalation testing." Process:
1. Analyze token structure from Burp Sequencer output: Output: List of valid session tokens. Two confirmed as administrative. Escalate to manual session hijacking verification via Burp Repeater. Scenario: Data harvesting via access-control flaw on a user-details endpoint Trigger: "We found that Process:
1. Inspect the response HTML: user data appears in table cells as Output: Complete user directory with credentials. Feed into privilege escalation and password reuse testing. Scenario: Baseline vulnerability fuzzing of a login form and authenticated function Trigger: "We need to fuzz every parameter in the login and in the user-detail page before concluding the assessment." Process:
1. Send the login POST and the user-details GET from Burp Proxy history to Intruder using "Send to Intruder." Intruder auto-marks all parameter values as payload positions.
2. Configure Sniper attack type. Load the universal fuzzing payload kit (SQL, XSS, OS command, path traversal, script injection, file inclusion strings). Configure Grep-Match with the standard error-string list ( Output: Two candidates (SQL injection in login username, reflected input in uid parameter). Escalate each to the dedicated vulnerability skill for confirmation and exploitation. This skill is licensed under CC-BY-SA-4.0.
Source: BookForge β The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws by Dafydd Stuttard, Marcus Pinto. This skill is standalone. Browse more BookForge skills: bookforge-skills
Scenario: Session token enumeration on an application with weak token generation Trigger: "The session tokens look partially sequential β I want to enumerate valid sessions for privilege escalation testing." Process:
1. Analyze token structure from Burp Sequencer output: Output: List of valid session tokens. Two confirmed as administrative. Escalate to manual session hijacking verification via Burp Repeater. Scenario: Data harvesting via access-control flaw on a user-details endpoint Trigger: "We found that Process:
1. Inspect the response HTML: user data appears in table cells as Output: Complete user directory with credentials. Feed into privilege escalation and password reuse testing. Scenario: Baseline vulnerability fuzzing of a login form and authenticated function Trigger: "We need to fuzz every parameter in the login and in the user-detail page before concluding the assessment." Process:
1. Send the login POST and the user-details GET from Burp Proxy history to Intruder using "Send to Intruder." Intruder auto-marks all parameter values as payload positions.
2. Configure Sniper attack type. Load the universal fuzzing payload kit (SQL, XSS, OS command, path traversal, script injection, file inclusion strings). Configure Grep-Match with the standard error-string list ( Output: Two candidates (SQL injection in login username, reflected input in uid parameter). Escalate each to the dedicated vulnerability skill for confirmation and exploitation. captures page titles; Name: captures user names from HTML tables. xsstest string or the full XSS payload unmodified is a candidate.Step 5: Handle Session Barriers Before Launching
Step 6: Launch the Attack and Triage Results
' produces a response containing quotation, syntax, or ODBC that differs from the '-- response (which may restore normal behavior); waitfor payload produces ~30-second delay.xsstest string was reflected unmodified.111111 alone, not as part of the submitted string.Inputs
Outputs
Parameter: [name]
Payload: [string]
Anomaly: [status/length/time/grep observation]
Suspected class: [SQL injection | XSS | OS command | path traversal | script injection | access control]
Next step: [manual verification approach]
Key Principles
Examples
000000-fb2200-16cb12-172ba72551. The final 3 hex digits increment predictably; the middle segment is static; the second segment partially increments.
2. Capture a request to an authenticated page (GET /auth/502/Home.ashx) that returns HTTP 200 for a valid session and HTTP 302 to login for an invalid one.
3. Configure Intruder Sniper: one payload position on the last 3 hex digits of the session cookie value. Payload type: Numbers, range 0x000β0xfff, hex format, 3-digit minimum. No custom grep needed β status code is the hit signal.
4. Launch. Sort results by Status. HTTP 200 rows = valid hijackable sessions.
5. Sort results by Length. Two HTTP 200 responses are significantly longer than the rest β these are more-privileged user sessions. Double-click to confirm admin content.GET /auth/498/YourDetails.ashx?uid=198 returns any user's full profile β we need to harvest all accounts.", Name: Phill Bellend , Username: phillb .
2. Configure Intruder Sniper: one payload position on Password: b3ll3nd uid. Payload type: Numbers, range 190β250 (start from known-good range, widen later). Session cookie as a fixed non-attack parameter.
3. Add three Extract Grep entries for Name: , Username: , Password: β each configured to capture text until the next <.
4. Launch. Sort by Status. HTTP 200 rows with populated extract columns = valid users.
5. Export tab-delimited results into a spreadsheet. Widen the UID range to capture all accounts.error, exception, quotation, syntax, ODBC, 111111, xsstest). Enable Payload Grep to flag reflected payloads.
3. For the user-details page, configure a session-handling rule: validate session before each request; re-login macro runs if session is invalid. This prevents the expired-cookie false-negative problem.
4. Launch both attacks. Sort each by Status, then Length, then Time.
5. Login form results: ' in username produces status 200, length 2941, with exception and quotation in grep β different from all other payloads which produce length ~1600. Confirmed SQL injection candidate.
6. User-details results: xsstest in uid is reflected in the response body (Payload Grep column shows match). Confirmed reflected input β escalate to manual XSS exploitation check.References
License
Related BookForge Skills
β‘ When to Use
π‘ Examples
000000-fb2200-16cb12-172ba72551. The final 3 hex digits increment predictably; the middle segment is static; the second segment partially increments.
2. Capture a request to an authenticated page (GET /auth/502/Home.ashx) that returns HTTP 200 for a valid session and HTTP 302 to login for an invalid one.
3. Configure Intruder Sniper: one payload position on the last 3 hex digits of the session cookie value. Payload type: Numbers, range 0x000β0xfff, hex format, 3-digit minimum. No custom grep needed β status code is the hit signal.
4. Launch. Sort results by Status. HTTP 200 rows = valid hijackable sessions.
5. Sort results by Length. Two HTTP 200 responses are significantly longer than the rest β these are more-privileged user sessions. Double-click to confirm admin content.GET /auth/498/YourDetails.ashx?uid=198 returns any user's full profile β we need to harvest all accounts.", Name: Phill Bellend , Username: phillb .
2. Configure Intruder Sniper: one payload position on Password: b3ll3nd uid. Payload type: Numbers, range 190β250 (start from known-good range, widen later). Session cookie as a fixed non-attack parameter.
3. Add three Extract Grep entries for Name: , Username: , Password: β each configured to capture text until the next <.
4. Launch. Sort by Status. HTTP 200 rows with populated extract columns = valid users.
5. Export tab-delimited results into a spreadsheet. Widen the UID range to capture all accounts.error, exception, quotation, syntax, ODBC, 111111, xsstest). Enable Payload Grep to flag reflected payloads.
3. For the user-details page, configure a session-handling rule: validate session before each request; re-login macro runs if session is invalid. This prevents the expired-cookie false-negative problem.
4. Launch both attacks. Sort each by Status, then Length, then Time.
5. Login form results: ' in username produces status 200, length 2941, with exception and quotation in grep β different from all other payloads which produce length ~1600. Confirmed SQL injection candidate.
6. User-details results: xsstest in uid is reflected in the response body (Payload Grep column shows match). Confirmed reflected input β escalate to manual XSS exploitation check.