Bug Bounty Hunting Essentials

Quick-paced guide to help white-hat hackers get through bug bounty programs

Carlos A. Lozano, Shahmeer Amir

• Publisher: Packt Publishing
• Year: 2018
• ISBN:
  9781788834438
• Edition: 1
• Topic: Computer Science
• Subtopic: Cyber Security
• Index: Computer Science

Get hands-on experience on concepts of Bug Bounty Hunting

Key Features

• Get well-versed with the fundamentals of Bug Bounty Hunting
• Hands-on experience on using different tools for bug hunting
• Learn to write a bug bounty report according to the different vulnerabilities and its analysis

Book Description

Bug bounty programs are the deals offered by prominent companies where-in any white-hat hacker can find bugs in the applications and they will have a recognition for the same. The number of prominent organizations having this program has increased gradually leading to a lot of opportunity for Ethical Hackers.

This book will initially start with introducing you to the concept of Bug Bounty hunting. Then we will dig deeper into concepts of vulnerabilities and analysis such as HTML injection, CRLF injection and so on. Towards the end of the book, we will get hands-on experience working with different tools used for bug hunting and various blogs and communities to be followed.

This book will get you started with bug bounty hunting and its fundamentals.

What you will learn

• Learn the basics of bug bounty hunting
• Hunt bugs in web applications
• Hunt bugs in Android applications
• Analyze the top 300 bug reports
• Discover bug bounty hunting research methodologies
• Explore different tools used for Bug Hunting

Who this book is for

This book is targeted towards white-hat hackers, or anyone who wants to understand the concept behind bug bounty hunting and understand this brilliant way of penetration testing.

This book does not require any knowledge on bug bounty hunting.

Cross-Site Scripting Attacks

Cross-site scripting (XSS) is a vulnerability derived from input validation errors in most part of the web applications. From a bug bounty hunter's approach, it is one of the most juicy bugs to look for in an application. It is the reason why XSS bugs are the most commonly reported bugs in bounty programs.

XSS exists due to a lack of validation controls in all the different inputs in an application. Traditionally, they are found in HTML forms that have interaction with the user; however, it is not the only kind of vulnerable input; it is also possible to find XSS vulnerabilities, because of the interaction between other applications, environmental variables, external data sources, and more.

The relevance of the XSS vulnerabilities is so important; evidence of that is this vulnerability is included in the OWAS TOP 10 as one of the most prevalent in the applications in the last 10 years.

One curious characteristic of this vulnerability, between others, is that it is focused on the client. Most of the vulnerabilities reviewed in this book are focused on the application itself, meaning that the application is exploited from a backend perspective in order to generate the failure.

As we will see, in this chapter XSS attacks need user interaction to be successful.

We will cover the following topics in this chapter:

• Understanding XSS attacks
• Detecting XSS in bug bounty programs
• Top XSS report examples

Types of cross-site scripting

There are different types of XSS; the most basics are as follows:

• Reflected XSS
• Stored XSS
• DOM-based XSS

We will describe all of them in detail during this chapter, but in the bug bounty hunter forums, it is possible to find other kind of XSS, such as these:

• Blind XSS
• Flash-based XSS
• Self XSS

We will also review them. Although they are part of the main XSS types (reflected, stored, or DOM-based), there are little variations that are important to know in order to write good reports, which expand support to the vulnerability that we are reporting.

Reflected cross-site scripting

In some literature, it is possible to find this vulnerability named first order XSS, but it is not a common name. However, this name describes how a reflected XSS works.

Let me explain the process and the impact with an example.

Imagine that it is a Sunday morning and you receive a call from your grandmother, who is so scared because all the money in her bank account has been stolen. You, as a good grandchild, enter the online bank application and review the account. All is correct: there is a transaction that moved all the money to another account.

When your grandmother calls the bank, the bank just answers that this transaction was executed with her valid credentials, and is not possible to do anything because all is correct.

How did this happen?

Talking with your grandmother, you discovered that a day ago she received a message by email from the bank with a promotion to win a vacation at Cancun. She logged in to the website and following the recommendation that you as a security expert gave to her: she checked in the web browser's address bar that the bank's domain was correct. She called to the bank again to confirm this promotion, but the assistant tells her that no one in the bank knows about the promotion. You know what happened now: your grandmother was the victim of a reflected XSS sent by an email to steal the credentials of her bank account.

Reflected XSS is a type of XSS that is executed at the moment. Mostly, it affects GET requests.

If you examine the email received by your grandmother, you can see that the email contains a link to the promotion; this link includes the valid bank's domain name, something like this:

 www.bankforoldpeople.com/access?account='><script><alert...

Yes, the domain is valid. But if you see the variable account, the value assigned to the variable does not appear like an account number; it actually is JavaScript code, you can identify it by the <script> tag, which is the tag used in HTML to insert a code script.

Now, you can infer that the account variable is vulnerable, it has a lack of input validation that allowed an attacker to inject JavaScript code and send a lot of emails with the malicious link to people in order to execute the attack.

This is the reason why this type of XSS is called first order, because you see the result of the XSS at the moment it is executed, but if you enter the real URL without using the malicious link, you will not see the attack. The attack just affects the user who is clicking the link.

Stored cross-site scripting

I will describe this kind of XSS, using a personal example from a past job. In order to understand, as in the first case, the way to exploit this vulnerability and its impact.

Around a year ago, I was working in a digital advertising agency; where there was an internal application with a lot of forms to create customer profiles and marketing campaigns.

There I was working as a QA engineer, and for one of my functional tests, I used the Intruder tool in Burp Suite to insert a list of values into the application's fields. Also, I added this string:

 '><script>alert(1)</script>

But, I kept in mind that this simple string attack may not work because in this company, the developers were using Laravel. Laravel is a PHP framework, currently used in a lot of projects, which includes input validation controls to avoid most common injection attacks.

I started the tests, inserting around 5000 values into the application, and after an hour I started to see some developers talking nervously between themselves, opening the code, training to modify some things, doing SQL queries.

The customers started calling the company, because the application started to fail, showing a lot of pop-ups in the browser. The quantity of pop-ups was so great that the application was impossible to be acceded, and if a customer tried to access to other application's section, the same thing happened.

What happened here?

Some lazy developers avoided using Laravel's methods to validate inputs, and wrote the code using PHP directly into the application. When Burp Suite's Intruder inserted the string, all the fields in the forms accepted the string. As I mentioned before, the forms were used to create customer profiles for marketing campaigns, so all this information was stored in a MySQL database to be consulted by the user afterward.

When the customers accessed the application to see the revenue generated by the cam...