BBC Ch 25: Automated Vulnerability Discovery / Fuzzing

Source: Bug Bounty Bootcamp by Vickie Li

Top bug bounty hunters automate the majority of their workflow: continuous recon, automated scanning, and immediate verification when a potential vulnerability is flagged. Fuzzing (fuzz testing) drives a large share of new CVE discoveries and is equally applicable to web applications.

Fuzzing is the process of sending a wide range of invalid and unexpected data to an application and monitoring it for exceptions. The goal is to induce unexpected behavior (crashes, errors, unexpected output) and determine whether it is exploitable.

Web application fuzzing targets common injection points to expose vulnerabilities like XSS, SQL injection, IDORs, open redirects, and authentication bypass – without requiring source code access.

A web fuzzer replaces marked injection points in requests with strings from a wordlist, fires the requests, and tracks server responses. Wfuzz uses the keyword FUZZ as the injection point marker:

wfuzz -w wordlist.txt http://example.com/FUZZ

This generates one request per wordlist entry, substituting FUZZ with each string.

Identify all locations where user input enters the application: URL path segments, query parameters, POST body parameters, HTTP headers, cookies.

Classify injection points by likely vulnerability:

# IDOR candidates -- numeric IDs
GET /email_inbox?user_id=FUZZ
POST /delete_user  (body: user_id=FUZZ)

# XSS candidates -- search/display fields
GET /search?q=FUZZ
POST /send_email  (body: title=FUZZ&body=FUZZ)

Match the wordlist to the vulnerability type:

• Path enumeration: directory wordlists (SecLists Discovery/Web-Content/)
• IDOR/ID fuzzing: numeric ranges (1-10000)
• XSS: XSS payload lists (SecLists Fuzzing/XSS/)
• SQLi: SQL injection wordlists (SecLists Fuzzing/SQLi/)
• Auth brute-force: credential lists (SecLists Passwords/)

Recommended resources:

• SecLists: https://github.com/danielmiessler/SecLists/
• Big List of Naughty Strings: https://github.com/minimaxir/big-list-of-naughty-strings/
• FuzzDB: https://github.com/fuzzdb-project/fuzzdb/

Also try randomly generated payloads – extremely long strings, mixed encodings, special characters (newline, null byte, line feed) – to provoke unexpected behavior and discover new vulnerability classes.

Burp Intruder (GUI, integrated with Burp proxy):

1. Right-click any intercepted request → “Send to Intruder”
2. Highlight injection points; click “Add”
3. Configure payload list in the Payloads tab
4. Note: free Burp throttles requests per minute; use Wfuzz for faster results

Wfuzz (CLI, unrestricted):

pip install wfuzz

Common Wfuzz commands:

Path enumeration (hide 404s, follow redirects):

wfuzz -w wordlist.txt -f output.txt --hc 404 --follow http://example.com/FUZZ

IDOR scanning:

wfuzz -w ids.txt http://example.com/view_inbox?user_id=FUZZ

HTTP Basic auth brute-force (single wordlist):

wfuzz -w wordlist.txt -H "Authorization: Basic FUZZ" http://example.com/admin

HTTP Basic auth brute-force (username + password lists):

wfuzz -w usernames.txt -w passwords.txt --basic FUZZ:FUZ2Z http://example.com/admin

Open redirect testing (verbose + follow to detect redirects):

wfuzz -w wordlist.txt -v --follow http://example.com?redirect=FUZZ

XSS reflection detection (filter for reflected payloads):

wfuzz -w xss.txt --filter "content~FUZZ" http://example.com/search?q=FUZZ

SQLi via POST body:

wfuzz -w sqli.txt -d "user_id=FUZZ" http://example.com/get_user

Interpret responses based on the vulnerability type being tested:

Think of fuzzing as a metal detector – it finds suspicious spots; you inspect them manually to confirm and assess impact.

Use both: static analysis when source is available, fuzzing for black-box targets. Neither replaces manual testing for business logic errors and multi-step vulnerabilities.

• Rate limiting: the server may throttle or ban your IP; use –delay in Wfuzz when necessary; always obtain permission before heavy fuzzing
• Limited impact assessment: without source code, classifying a bug's severity requires additional manual testing
• Misses logic errors: fuzzing won't catch business logic bugs or vulnerabilities requiring multiple coordinated steps
• False positives: always manually verify each anomaly before reporting

• Read the documentation and source code of every tool you add (Wfuzz, Sublist3r, etc.)
• Understanding how tools work teaches you how to write your own
• Modify open source tools to add features; contribute back if useful
• Automate recon and basic scanning; spend manual time on logic and chaining

1. Identify all data injection points in the target; classify each by likely vulnerability.
2. Select appropriate payload wordlists (SecLists, FuzzDB) for each injection type.
3. Run Wfuzz against each injection point with the matching payload list; throttle if necessary to avoid disruption.
4. Analyze results for status code, response length, and response time anomalies; manually verify each candidate before reporting.