edoverflow / bugbountyguide

Bug Bounty Guide is a launchpad for bug bounty programs and bug bounty hunters.

Hi 👋

I am a web designer, developer, security researcher, and have experience triaging for numerous vulnerability disclosure programmes.

In 2016, I joined Gratipay’s Blue Team where I operated their bug bounty programme. Subsequently, in 2018, I joined HackerOne as a Security Analyst. While at HackerOne, I had the privilege of triaging in-person alongside organisations such as GitHub, Salesforce, and the United States Marine Corps.

Currently, I am a Senior Pentester at Cure53, where I use my expertise to help clients strengthen their security posture by conducting security audits and source code reviews.

Outside of work, I enjoy staying active and maintaining a strong dedication to swimming, honed during my time as a student on the University of Warwick’s Sports Scholarship programme.

---

edoverflow.com • LinkedIn

bugbountyguide's Issues

Proof of concept feedback

Hi @EdOverflow - thanks a bunch for putting this together, having this all in one place is really helpful for the community. I've read through the hacker sections and wanted to provide some feedback on the proof of concepts section in particular.

Arbitrary code execution

The examples are for arbitrary command execution vulnerabilities, not code execution. I'd suggest to add both sections and add examples for code execution, like <?php echo 7*7; ?> or print 7*7.

SQL injection

These examples are good, but only work if the attacker can influence the value of a column. Perhaps it'd be a good idea to add additional PoCs for injections in the GROUP BY and ORDER BY clauses and for blind / time-based SQL injections. Each of them requires a difference exploit strategy. If you want to keep this as lightweight as possible, you could also refer to some great articles here.

Information disclosure

Perhaps refer to IDORs here to make sure hackers tag the most specific CWE (although CWE-200 is technically also correct). I personally like this vulnerability type because it's easy to start with because it often doesn't require a ton of technical experience to find or exploit. I'd also advise the hackers to use two accounts instead of "stopping immediately" (which implies they might've accessed someone else's information).

Server-side request forgery

It's unclear what you mean exactly with this PoC. Are you referring to hitting an endpoint on localhost or a metadata service? If so, I'd be slightly more elaborate here to avoid confusion that any SSRF gives access to local files. I'd say a safe SSRF PoC depends on multiple factors, but you could give some generic guidelines here on what to try. If you want, you could refer to HackerOne's SSRF blog post for additional reading.

Local file inclusion

I'd point out the difference between a local file read and local file inclusion here. The former only allows the attacker to read local files (e.g. /etc/hostname), whereas the latter allows you to execute code (the term inclusion comes from the PHP function include / require, since those often took (take!) unsanitized user input that causes path traversals. Perhaps also mention a remote file inclusion while you're at it.

I'll provide feedback on other sections in separate issues. Thanks again, great initiative!

Georgian version

Hunter section is translated full. location is bunbountyguide/ga directory.
https://github.com/ghsec/bugbountyguide/tree/master/ga