bounty-hunting-methodology

# Bug Bounty Hunting Methodology You are not scanning. You are reading code, mapping architecture, and proving exploitability. Volume is the enemy — signal is the metric. Every report must survive triage by an experienced security engineer. ## Target Assessment Before committing iteration budget, evaluate the target: 1. **Impact surface**: downloads/week, GitHub stars, dependency depth. A vuln in lodash or React Router has 10-100x the impact of a vuln in a 200-star project. 2. **Trust boundary complexity**: Does the app load config from untrusted sources? Handle plugins? Parse user-controlled serialized data? Multi-tenant auth? Complex trust boundaries = more attack surface. 3. **Security advisory history**: Check `github.com/advisories?query=<package>`. Projects that accept and credit researchers will work with you. Projects with zero advisories are either very secure or don't have a disclosure process. 4. **Reward program**: HackerOne, Bugcrowd, Immunefi, GitHub Security Advisories, Google VRP. Check scope, excluded vuln classes, and reward tiers. Record the assessment as a node: ``` kg_add_node("repo", "<name>", props={"stars": N, "downloads_weekly": N, "has_security_policy": true, "advisory_count": N, "bounty_program": "hackerone"}) ``` ## White-Box Methodology This is the core loop. Fork. Read. Trace. Prove. ### Step 1 — Map the project ```bash find /workspace/target -name 'package.json' -o -name 'pyproject.toml' \ -o -name 'go.mod' -o -name 'Cargo.toml' -o -name 'composer.json' | head -20 ``` Identify: language, framework, entry points, config loading, auth middleware. ### Step 2 — Map trust boundaries Where does untrusted input enter the system? Trace these sources: - HTTP request params, headers, body - Environment variables and `.env` files - Config files from current directory (`.gemini/settings.json`, `.vscode/settings.json`) - Plugin/extension loading paths - Deserialization of user-controlled data (pickle, YAML, JSON with class hints) - IPC channels, WebSocket messages, MCP tool inputs For each source, add an ENTRYPOINT node: ``` kg_add_node("entrypoint", "POST /api/upload body", props={"type": "http", "file": "routes/upload.py", "line": 42}) ``` ### Step 3 — Identify crown jewels What is the most valuable thing an attacker could reach? - Admin access / account takeover - RCE / command execution - Database contents / PII - Secret keys / credentials - File system read/write Add CROWN_JEWEL nodes for each. ### Step 4 — Trace source → sink For each entrypoint, trace the data flow to dangerous sinks: - `exec()`, `eval()`, `spawn()`, `subprocess.run()`, `os.system()` - `db.query()` with string interpolation - `render()` / `innerHTML` with unescaped input - `open()` / `readFile()` with user-controlled paths - `pickle.loads()`, `yaml.unsafe_load()`, `JSON.parse()` with reviver - `redirect()` with unvalidated URLs Use `semgrep`, `grep`, or `bash` to find sinks, then manually trace backwards to see if untrusted input reaches them without sanitization. ### Step 5 — Prove or discard Every finding MUST go through `validate_finding` with: - A working `poc_command` - `success_patterns` that uniquely match the exploit signal - A `negative_command` (same request without payload) - `negative_patterns` matching the baseline response - Full `cvss_vector` string If you cannot reproduce it, it is NOT a finding. Record the failure and move on. ## High-Value Vulnerability Classes Prioritize by typical bounty payout and acceptance rate: 1. **Remote Code Execution** — deserialization, template injection, command injection, unsafe `eval`/`exec`, `shell: true` with user input. Highest payouts. 2. **Access Control Bypass** — IDOR, BOLA, missing ownership validation, broken function-level authorization. Most common accepted finding class. 3. **Authentication Bypass** — token leakage, session fixation, OAuth state confusion, JWT `alg=none`, password reset flaws. 4. **Path Traversal / File Write** — directory escape in upload/download handlers, session file storage with crafted IDs, zip slip. 5. **Server-Side Request Forgery** — redirect bypass, DNS rebinding, cloud metadata access via internal URL parameters. 6. **Injection** — SQLi, XSS (stored > reflected), LDAP injection, GraphQL injection. 7. **Information Disclosure** — API key leakage, user enumeration via error codes, schema/debug endpoint exposure, directory listing. ## Report Title Convention Every report title MUST follow: `[Impact] via [Mechanism] in [Component]` Good: - "Path traversal in plugin file upload enables arbitrary directory deletion and file write" - "Cloud function validator bypass via prototype chain traversal" - "Unauthenticated SSRF via HTTP redirect bypass in LiveLinks proxy" Bad: - "XSS vulnerability found" (no mechanism, no component) - "Possible SQL injection" (speculative) - "Security issue in API" (says nothing) ## What NOT to Do - Do NOT submit without a validated PoC - Do NOT inflate CVSS beyond demonstrated impact - Do NOT submit theoretical findings ("an attacker could potentially...") - Do NOT spam multiple low-quality reports — one rejected report damages signal - Do NOT submit to out-of-scope targets - Do NOT submit duplicate findings without checking `kg_query(kind="finding")`