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 — BAC 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.
Recommended Addon: Logger++
While you are testing the website/app for BAC bugs — you can highlight all GET requests to critical actions. E.g.
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 protection can be bypassed sometimes. Try to switch the POST method to GET or remove token value from a key -
With referrer protection, you can try to append your own domain to a referrer, like this
And the third basic rule while performing bug bounty hunting — is to put a basic payload in all possible inputs:
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:
<script> element itself:
<script> let a = "qwe'"<x</" <script>
That's all for now! Thanks for reading 👍
Follow me on Twitter - twitter.com/therceman
I Tweet & Write about WebDev & InfoSec