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 (kg_record from your KG slot):

kg_record('[{"kind": "Repository", "key": "repo::<name>", "label": "<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

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, record an ENTRYPOINT observation:

kg_record('[{"kind": "Entrypoint", "key": "entrypoint::POST /api/upload body",
  "label": "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 your recorded findings (workspace findings/ + inspect_evidence)