How To Start Bug Bounty Hunting

I recommend registering on @BugCrowd, @Hacker0x01, @intigriti

Searching for bugs in the wild (not on a bug bounty platform) is great, but not for the start.

Bug bounty platforms can give you very interesting private invites over time.

Try focusing on programs that have a wide scope, where you can manage users (create roles), docs, images, etc.

And then start with a simple — create two users (one basic user & second admin), open two browsers, and start testing for BAC (Broken Access Control) vulnerability.

In short — this is the type of vulnerability, where a basic user can perform admin actions.

Some of these vulnerabilities can be found using direct links to sections/endpoints, but others will require you to modify requests that are sent to the browser

I recommend using @Burp_Suite for requests capture & modification. You can download Community Edition for Free.

While you are testing the website/app for BAC bugs — you can highlight all GET requests to critical actions. E.g. web/delete_user?id=1

Requests with critical actions that can be directly sent to a user are treated as a CSRF (Cross-Site Request Forgery) vulnerability

POST requests can be used too to perform CSRF attack, but usually has CSRF protection mechanism in place (like csrf_tokens or referrer check)

And the third basic rule while performing bug bounty hunting — is to put a basic payload in all possible inputs: qwe’”<X</

And just watch text reflection on a website. If you will see somewhere qwe’” (without angle brackets) — this could be a chance of XSS

Additionally, search for qwe text in the source code of the page. Use

Developers Tools in the browser for this task. Some of the input payloads can be reflected in tag parameters: <a class=”qwe’”<x</”>

Or in <script> element itself: <script> let a = “qwe’”<x</” <script>