====== 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.

===== What Is Fuzzing? =====

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.

===== How a Web Fuzzer Works =====

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:
<code>
wfuzz -w wordlist.txt http://example.com/FUZZ
</code>

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

===== The 4-Step Fuzzing Process =====

==== Step 1: Determine Data Injection Points ====

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:
<code>
# 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)
</code>

==== Step 2: Choose the Payload List ====

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.

==== Step 3: Fuzz ====

**Burp Intruder** (GUI, integrated with Burp proxy):
  - Right-click any intercepted request -> "Send to Intruder"
  - Highlight injection points; click "Add"
  - Configure payload list in the Payloads tab
  - Note: free Burp throttles requests per minute; use Wfuzz for faster results

**Wfuzz** (CLI, unrestricted):
<code>
pip install wfuzz
</code>

Common Wfuzz commands:

Path enumeration (hide 404s, follow redirects):
<code>
wfuzz -w wordlist.txt -f output.txt --hc 404 --follow http://example.com/FUZZ
</code>

IDOR scanning:
<code>
wfuzz -w ids.txt http://example.com/view_inbox?user_id=FUZZ
</code>

HTTP Basic auth brute-force (single wordlist):
<code>
wfuzz -w wordlist.txt -H "Authorization: Basic FUZZ" http://example.com/admin
</code>

HTTP Basic auth brute-force (username + password lists):
<code>
wfuzz -w usernames.txt -w passwords.txt --basic FUZZ:FUZ2Z http://example.com/admin
</code>

Open redirect testing (verbose + follow to detect redirects):
<code>
wfuzz -w wordlist.txt -v --follow http://example.com?redirect=FUZZ
</code>

XSS reflection detection (filter for reflected payloads):
<code>
wfuzz -w xss.txt --filter "content~FUZZ" http://example.com/search?q=FUZZ
</code>

SQLi via POST body:
<code>
wfuzz -w sqli.txt -d "user_id=FUZZ" http://example.com/get_user
</code>

==== Step 4: Monitor Results ====

Interpret responses based on the vulnerability type being tested:

^ Vulnerability ^ What to look for ^
| Path enum | 200 status = valid path; 404 = not found |
| IDOR | 200 with content vs 403/404; response length differences |
| SQLi | Response time spike (time-based), length increase (data extracted), status code change |
| XSS | Payload reflected in response (use ''content~FUZZ'' filter) |
| Open redirect | Redirect to your domain (use ''--follow -v'') |

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

===== Fuzzing vs. Static Analysis =====

^ | Static Analysis | Fuzzing |
^ Source code required | Yes | No |
^ Tests live behavior | No | Yes |
^ Finds logic errors | Yes | Rarely |
^ Finds injection bugs | Yes | Yes |
^ Black-box friendly | No | Yes |

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.

===== Pitfalls =====

  * **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

===== Building Your Toolkit =====

  * 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

===== 4-Step Checklist =====

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