====== Ch 2: Sustaining Your Success ======

Source: Bug Bounty Bootcamp by Vickie Li (No Starch Press, 2021)

===== Writing Good Reports =====

A report is how you get paid and build reputation. Bad writing = low payouts + duplicates marked invalid.

**8-step report structure:**

  - **Title** -- one sentence: vuln type + location + impact. Example: "Stored XSS in /profile/bio allows attacker to steal session cookies"
  - **Summary** -- 2-3 sentences. What is the bug, where is it, what can an attacker do?
  - **Severity** -- CVSS score + label (Critical/High/Medium/Low). Justify your rating.
  - **Steps to reproduce** -- numbered, exact, no assumptions. Another person must be able to reproduce with zero context.
  - **Proof of concept** -- screenshots, HTTP requests/responses, video. Show it working.
  - **Impact** -- explain real-world consequences. Who is affected? What data is exposed? What actions can be taken?
  - **Mitigations** -- suggest a fix. Not required but earns goodwill.
  - **Validate** -- test your own PoC before submitting. If it doesn't reproduce 100%, find out why first.

===== Report States =====

After submission you'll see one of these:

  * **Need more info** -- triage can't reproduce; provide more detail
  * **Informative** -- acknowledged but won't fix (low risk or by design); no payout
  * **Duplicate** -- someone reported it first; no payout
  * **Not applicable (N/A)** -- out of scope or not a valid vulnerability
  * **Triaged** -- accepted, being fixed; you'll get paid when resolved
  * **Resolved** -- fixed; payout issued

===== Handling Duplicates and N/As =====

  * Duplicates happen. Don't be discouraged. Look at public disclosures to learn the pattern.
  * If marked N/A and you disagree, respond professionally with additional impact evidence.
  * Never argue aggressively -- you need the relationship with the program.

===== Building Relationships =====

  * Respond quickly when triage asks for clarification
  * Be helpful: offer to verify the fix
  * Keep communication professional even when payouts feel unfair
  * Researchers with good reputations get private program invites

===== Why You're Failing =====

Common reasons beginners don't find bugs:

  * **Testing too shallow** -- only checking the obvious, not chaining small issues
  * **Only hunting well-known vulns** -- everyone tests the login page for SQLi; look where others don't
  * **Not understanding the application** -- you can't find logic bugs if you don't understand the intended workflow
  * **Giving up too fast** -- recon takes time; bug hunting requires patience
  * **Ignoring new features** -- new code = new bugs; watch changelogs and announcements

===== What to Do When Stuck =====

  * Read public reports on HackerOne Hacktivity for the same target
  * Look at the target's changelog/blog for new features
  * Change your perspective: try a different user role, a different browser, mobile vs. desktop
  * Take a break and come back with fresh eyes
  * Switch targets temporarily and return later

===== Severity Quick Reference =====

| Severity | Examples |
|---|---|
| Critical | Account takeover, RCE, mass data exposure |
| High | Privilege escalation, significant data leak, auth bypass |
| Medium | CSRF, stored XSS (limited scope), IDOR (limited data) |
| Low | Reflected XSS, open redirect, minor info disclosure |
| Informative | Missing security headers, self-XSS |