Introduction to Bug Bounty

What we are going to learn?

1. How to identify, exploit, and remediate the top web security vulnerabilities, as well as much more arcane bugs.
2. How to properly handles cryptography.
3. How to design and review applications from a security standpoint
4. How to operate as a bug bounty hunter or a security consultant
5. Much cooler stuff

Note: Brush up your web request skills with your language of choice. If using Python ‘requests’ package is my personal favorite.

Link to Official Python Requests documentation

Requests: HTTP for Humans™ - Requests 2.25.1 documentation

Must-have Tools

Burp proxy ( free edition is perfectly fine)

Firefox Browser

This allows you to watch all HTTP(S) communication, intercept and modify requests, and replay existing requests

You will use this constantly in both your coursework and exams

Firefox allows you to set proxy settings specified in the browser, rather than setting them system-wide

This will be your friend when you’re testing, to isolate an application

Breaker’s Mindset

1.You’re here to learn how to break things before anyone else does so that vulnerabilities can be fixed before attackers get them.

1.1 To do that, you need to understand how attackers operate, what their goals are, and how they think.

2The most important tenet of the breaker mindset is this: pushing a button is the most effective way to discover what it does.

2.1 If you don’t understand what an application is doing and why it’s doing it, you’re going to have a hard time finding ways to break it.

3. Prioritizing your efforts is crucial to ensure that where there are still bugs, the impact will be relatively low. Making an accurate assessment of high-risk areas is critical.

4. When assessing an application, find every bit of functionality you can. Once you have a rough list of all of the bits of application, consider this: If I was an attacker, what would my goal be?

Findings

For each vulnerability include the following:

1. Title — E.g. “Reflected Cross-Site Scripting in profiles”
2. Severity
3. Description — Brief description of what the vulnerability is
4. Reproduction Steps — Brief description of how to reproduce the bug; preferably with a small proof of concept
5. Impact — What can be done with the vulnerability?
6. Mitigation — How is it fixed?
7. Affected Assets — Generally a list of affected URLs.

Severity

This is handled differently just about everywhere, but I recommend basing severity on the difficulty of exploitation and potential business impact.

1. Informational — issue has no real impact
2. Low — The business impact is minimal
3. Medium — Potential to cause harm to users, but not revealing data
4. High — Potential to reveal user data or aids in the exploitation of other vulnerabilities
5. Critical — Hig risk of personal/confidential data exposure, general sys compromise, and another severe impact to the business.

Let us see an example

Can you find what’s wrong with the code… It’s your first bug

Explanation:-

The code is pretty straightforward:

1. Was a ‘name’ parameter passed via GET? if so, print ‘Hello <name>!’ in an h1 tag.
2. Print a form for the user to enter their name

What could possibly go wrong with such a simple piece of code?

What would happen if you were to go to this page?

http://vulnerable.example.com/page.php?name=<script>alert(1);</script>

The HTML would then be: <h1>Hello<script>alert(1);</script>!</h1>

What you’ve just seen is an example of reflected cross-site scripting.

In essence, a parameter that an attacker control is directly reflected back to the user. This could allow the injection of raw HTML or Javascript and allow an attacker to perform an action in the context of another user.

SOCIALs

JavaScript is not available.

ORION AMVS

https://github.com/Gitcomplex

https://www.instagram.com/_dipanshu_7/