Bug Bounty Hunting
A simple and minimalist guide to start into Security Researching, specifically in the Bug Bounty.
What to do when starting in Bug Bounty Hunting or Security Researching
Select just one program / target with:
Good Policy
Interesting Scope
Good Response Time
Big Bounty Prices
Many Reports per Month
Bug Bounty Hunting Methodology and Mindset
Understand the whole application. Both front-end and back-end, its features, policies of the company, services, APIs, etc.
Have a specific idea of a workflow for exploit a specific functionality. One specific intent for some feature. If the idea doesn't work, trying another way and keep researching more ideas.
Essential Checklist
Discover and get familiar with the application
Review source-code and documentation
Authentication & Authorization attacks
Business Logic Errors
SSRF, IDOR and XSS
Other attacks (depends on the app)
Reporting
HackerOne Top Ten Vulnerabilities
XSS
Improper Access Control - Generic
Information Disclosure
Insecure Direct Object Reference (IDOR)
Misconfiguration
Privilege Escalation
Improper Authentication - Generic
Business Logic Errors
Open Redirect
Improper Authorization
Top Ten Vulnerabilities | HackerOne
Where to look for Vulnerabilities
Where to look for SSRF
In query or parameters like
redirect,url,next, etc...When server is fetching data like JS files, CSS or Images from another host.
Features depending on the app which check the "status" or something similar.
The key is to get access to the Internal Network and have access to the files and resources inside.
Where to look for SQLi
Forms with POST Requests, if the Response returns Status Code 500 (Internal Server Error) appear to be vulnerable.
Inputs that query the database for values such as usernames, passwords, IDs, etc. ....
Always try to inject queries to the database to find out how to get access to the database or execute queries and get information.
Where to look for Business Logic Errors
These kinds of vulnerabilities are unique bugs that are found by original techniques which can be performed by trying different methods of hacking. So the majority of those attacks depends especially on the app and the attacker.
It can be found by analyzing the source code and trying to exploit some specific features of the application.
Most common of business logic errors occur when you break the logic of the application and try to exploit the use of it.
Where to look for LFI or RFI (Path Traversal)
In order to perform Path Traversal it's necessary to identify where the application is loading an internal file like:
file://../../app/index.php. Generally occurs in endpoints which has parameters like: "file", "view", "download", "doc", etc...Try with different encodings to bypass WAF like HTML, Unicode, URL, Double URL, Hex, etc.
Try perform path traversal by injecting
..0x2f..0x2f..0x2f..0x2f../etc/passwd(if Linux), or as wellfile:///etc/passwd, etc...
Where to look for XSS
When submit a value inside parameters and then it is reflected in the DOM (HTML), try to inject code to escape HTML Tags and create your custom XSS payloads. For example:
>;'</input><svg ONly ONLoad=confirm()>//To understand how to craft XSS payloads, you need to: 1. Know HTML. 2. Understand the basics of JavaScript, and 3. Have fun crafting XSS payloads.
In order to bypass WAF rules it is usually necessary to encode the characters in encodings processed in the back-end. Some of them are the following: HTML encoding, Hex Encoding, URL and double URL Encoding, Unicode Escapes, etc...
Keep in mind that "If WAF is too hard to bypass, try in another endpoint". (Not all endpoints are vulnerable).
Where to look for IDOR
"IDOR" which stands for "Insecure Direct Object Reference" is a vulnerability that occurs when the value as an ID or object identifier is modified and an attacker gains access to sensitive information or unauthorized actions. Typically they are BOLA (Broken Object Level Authorization) or BFLA (Broken Function Level Authentication).
Let's take this example: You have intercepted with Burp Suite or Caido a request whose path is something like this:
/api/v2/current/view. Here are many attacks to probe: 1. Changev2tov1,v3, or just delete it. Then try changingcurrentto an email (victim@example.com), application user id (2341), etc....You can also try changing
/viewto/edit,/delete, or also/create. These are some of the techniques frequently found in vulnerable APIs when the back-end is not sanitized, and are part of BFLA attacks.
Where to look for Open Redirect
The most common parameters to test for Open Redirect are:
redirect,next,url,continue,returnUrl,goto, etc...If these parameters are user-controlled and not validated, the app might redirect to an external malicious domain.
Try injecting values like:
?redirect=https://evil.com?next=//evil.com?url=https://whitelisted.com@evil.comEncoded:
%2F%2Fevil.com,%68%74%74%70%3A%2F%2Fevil.com
Try relative path tricks:
/redirect?next=/\evil.comor similar.You can also test with payloads that combine
@,//, or use double encoding.Some endpoints use client-side redirects (JavaScript or meta refresh), so check how the redirect is handled.
These vulnerabilities are mostly used for phishing attacks or to steal sessions. Always check if you can redirect the victim to a domain outside of the application.
Last updated
Was this helpful?