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
You can use ChatGPT to know the Impact but never for redaction.
Remember always never reveal any sensitive information!

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)
Miconfiguration
Priviege 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 uniques bugs that are found by original techniques which can be performed by trying differents methods of hacking. So the mayority 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 inyect ..0x2f..0x2f..0x2f..0x2f../etc/passwd (if Linux), or as well file:///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 you 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 they 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 vulnerables).

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. Change v2 to v1, v3, or just delete it. Then try changing current to an email (victim@example.com), application user id (2341), etc....
You can also try changing /view to /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.

PreviousTools and Hacks NextStatic Analysis

Last updated 1 month ago

Was this helpful?

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 uniques bugs that are found by original techniques which can be performed by trying differents methods of hacking. So the mayority 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 inyect ..0x2f..0x2f..0x2f..0x2f../etc/passwd (if Linux), or as well file:///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 you 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 they 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 vulnerables).

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. Change v2 to v1, v3, or just delete it. Then try changing current to an email (victim@example.com), application user id (2341), etc....

You can also try changing /view to /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.