No software is required for this chapter, though we will cover tools that will be used later on in the examples.

You can find the short code snippet referenced in the last section on OWASP's XSS Filter Evasion Cheat Sheet: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet.

The web is exploding—more people are using it to do more, in more varied ways, than at any point in its short history.

The phone is a perfect example of the rise of digital life. Since its invention at the end of the 20th century, it's expanded from a minor technical elite to over sixty percent of the world's population – more than five billion people are slated to have phones by the end of 2019. Our tiny pocket computers have conquered the world in under 30 years. Like the Big Bang, phone usage hasn't exploded so much as expanded at a stupendous rate, inflating to encompass the majority of the world's population. From the landline void came the spark of a mobile, unbounded future, and almost as quickly as the idea was conceived, it was realized.

The following chart from the UN's 2015 study on its progress towards the Millennium Goals captures the extent to which phone ownership grew to encompass nearly everyone in the world just through the early 2010s:

As a result of that expansion in internet access and a parallel increase in the web's complexity, more people are able to get online easily and are capable of doing more once they're there. Shopping, banking, socializing – an increasing part of our lives is lived online. And thanks to the data analysis of wunderkind artificial neural networks (algorithms designed to replicate the mathematical model of the human brain and its astounding success at pattern-recognition), trends point to more data collection. Neural nets are complicated to write but easy enough to use – as long as you feed them enough information. Our devices know more about us than ever and they're learning more every day.

This graph shows how much data is being created (or is estimated to be created) every minute over the next couple of years. The y-x axis on the following graph is measured in zettabytes (ZB): 1 ZB = 1 billion terabytes (TB). The numbers are staggering:

More applications performing more complex services for more people and managing more data leads to things breaking. The demand for web developers has soared as companies try to realize their technical aspirations, but supply has not kept up with the almost unlimited appetite for development work. Coding bootcamps, online courses, and other alternatives to a four-year degree have become a popular entry point for a career in software engineering, but there's still a large gap between what the programming companies want done versus the programmers who are available and capable of doing it. As demands on developer time and attention have increased, security concerns once avoided as costly and nonessential have ballooned into crises for inattentive businesses, as vulnerabilities have led to data breaches, commercial exploitation, identity theft, and even espionage by state actors and criminal syndicates.

Bug bounties are the crowdsourced alternative to an expensive, in-house security apparatus. Technology companies (from mega corps to small, five-person start-ups) have embraced using public bug bounty programs to find the sort of faulty logic and mishandled data-processing in their applications that hackers typically use as footholds for larger campaigns. By finding vulnerabilities before they become exploits, companies can pay for work that directly reduces their exposure without having to cover the cost of a full security audit. Some companies choose to participate in third-party platforms, such as Bugcrowd or HackerOne, in order to standardize their payouts, submission report formatting, rules of engagement, and target lists, while others are large enough to run a program under their own umbrella.

Either way, by participating as a researcher, you get paid to apply your skills. And since many bug bounty marketplaces also track things such as the number of bugs you've found, their severity, and your general success rate, doing third-party research on public platforms can also be a great bridge to more work in security. If you're coming from a non-traditional background or don't have formal education in security, it could help make the case you've got the necessary skills to be productive in the field. You can do all of this while – by responsibly following the discovery and disclosure process – making the target application, and the general web, safer.

This book assumes a familiarity with both web application engineering and the basics of web application security. Any experience with the frontend technologies that will provide the interface and context for many of your discoveries is an asset, including a basic understanding of HTML/CSS/JS, and the DOM; the client-server relationship, session management (cookies, TTL, and so on); and the browser environment. In addition, a general acquaintance with the RESTful API architecture, popular application frameworks and languages (Django/Python, RoR/Ruby, and so on), common application security techniques, and common vulnerabilities, will all be handy. You might be a full-time security researcher, a moonlighting web application engineer, or even just a programming enthusiast with a light background and a historical interest in security – you'll all find something useful within these pages. If you're just beginning, that's OK too – working through the step-by-step walk-through in later chapters will help you develop as a security researcher; you just might need to fill in the gaps with outside context.

In addition to these topics, it's assumed you'll also have experience using the command line. While many great graphic tools exist for conducting and visualizing penetration testing engagements, and we'll use many of them, the CLI is an invaluable tool for everything from package management, to real-time pentesting execution, to automation. And while many of the tools used will have a compatible Windows counterpart, the actual engagements will be conducted (for the most part) on a 2015-generation MacBook Pro loaded with High Sierra (10.13.2), if you are working on a Windows PC, you can still participate by using a virtual machine or emulation software.

All of the tools we'll use in this book will be free – you shouldn't need to purchase anything outside of this work to recreate the walk-throughs. In the survey of other security software not used directly in our engagements in Chapter 12, Other Tools, there will be a discussion of other technologies (paid and free) you can leverage for extra functionality.

Here's a brief overview of some of the technologies we will be using:

• Burp Suite is a versatile program that can intercept web traffic (Burp Proxy), trigger application information submission (Burp Intruder), scan input against malicious code snippets (Burp Scanner), and – with the possibilities offered by extensions – a multitude of other things. We'll go over both using the native Burp functionality as well as how to incorporate simple extensions. Some of the paid functionalities, such as Burp Scan, will only receive an overview, in favor of focusing on the features available in the free version.
• Nmap, sqlmap, wfuzz, arachnid, and other CLI programs are great for their ability to be assembled into larger workflows, feeding information into adjacent tools (Burp and others), kicking off other automation, or consistently visualizing a target's attack surface.
• Deliberately vulnerable web applications are a different category of tooling – less for use in an actual pentesting engagement and designed more to either test out new ideas or calibrate an existing method or technology for those times when you need to return a positive result for a specific vulnerability. We'll be doing both with our use of deliberately vulnerable web apps, such as Google Gruyere, Target Range, DAMN vulnerable web app, and others. You can find a list of more DVWA in the sites section of Chapter 13, Going Further.

While we'll be going through the setup for these tools as we use them, it's still a good idea to poke around their installation and documentation pages. Because of their depth, many of these tools will have useful functionalities that we simply won't be able to completely cover in the course of our work. We'll also only skim the surface of tools not specific to security—the note—taking, logging, and other general productivity functionality represented by those apps can easily be replaced by whatever analogue you're most comfortable with.

In addition to becoming familiar with these tools (and more) by the end of this book, you will also learn how to look for, successfully detect, and write a bug submission report for vulnerabilities associated with XSS, SQLi and NoSQLi, CSRF, XEE, data leakage, insecure session management, and unvalidated redirects, as well as framework and language-specific vulnerabilities, including sites powered by WordPress, Django, and Ruby on Rails applications. You'll also learn how to write a report that maximizes your payout, where to direct your attention to maximize your chances of finding a vulnerability, what vulnerabilities don't lead to payouts, preparing for your pentesting sessions, how to stay within the rules of engagement for a session, and other general tips for being productive – and profitable – as an independent security researcher participating in bug bounty programs.

Getting actual experience with penetration testing for the purpose of participating in a bug bounty program is key. You'll ultimately learn the most from taking the tools explored here and applying them to your own targets, so as you work through the book, you're encouraged to sign up with a third-party community and start your first forays into security research. As long as you adhere to the rules of engagement and are respectful of the app and its users, you can start trying out the techniques explored in these pages. Participating in forum discussions, reading about other users' experiences, following blogs, and generally being a part of the security community can also help you get a sense of effective strategies. Reading bug report submissions from other researchers who have gotten the OK to disclose their findings is a fantastic way to start understanding what makes a submission report effective and what vulnerabilities are typically discovered where.

A final word before moving on:

The techniques and technologies described in this book are solely for the purpose of participating in approved, ethical, White Hat penetration testing engagements so that you can find bugs and report them to be patched for a profit.

The lessons learned in this work should be used responsibly:

• They should not be applied to a website against its owner's permission
• They should not be applied to data or logic the website's owner considers out-of-scope
• They should not in any way be weaponized – taken beyond the vulnerability stage and made into proper exploits

Here's a quick example of what's meant by weaponized.

Let's say you find a stored XSS vulnerability, where improper data-sanitation is causing a comment thread to allow unescaped HTML to potentially store malicious code. You use the Burp Intruder tool and a manual follow-up to submit a code snippet demonstrating that you can store (and later execute) an arbitrary piece of JavaScript. The snippet in question is a pretty simple test – it executes an alert() function within an improperly sanitized src attribute attached to an <img> HTML tag:

<IMG SRC=javascript:alert('XSS')>

There's nothing wrong with using an alert() or console.log() call to test whether JavaScript is being executed in a possible XSS instance – although, when using alert() or logging, it's good to remember to output some info about where the XSS is happening (for example, alert(window.location.href)).

But there is something wrong with turning the vulnerability into an exploit. Once the XSS vulnerability is confirmed, it's easy to find malicious JavaScript to do more nefarious things. Running that malicious code –even in a limited way – risks corrupting application data or processes or other things that open you up to legal liability.

It's helpful to imagine how the vulnerability could be exploited – many bug bounty programs want to hear a specific scenario regarding your vulnerability included in your submission report so they can know whether it's severe enough to trigger a payout. Sometimes even the form of that scenario – how much damage you can make the case that an attacker could do – can drastically affect your reward.

So it's good to put some thought into the exploit's general form – with stored XSS, you could rewrite critical parts of the page where the script is being executed, or grab an authentication cookie and send it to a server listening for those credentials, or other attacks – but assessing the impact of that exploit still falls short of writing code that damages people and processes.

Don't write exploit code. If you're in the United States, the legal penalties are severe – as of this writing, the Computer Fraud and Abuse Act (CFAA) means that even a slight violation of a site's terms of service can result in a felony. Businesses are also quick to prosecute independent researchers not abiding by their rules of engagement, which is the condition researchers must follow when probing an application for vulnerabilities. Even if there's no threat of legal action, civil or criminal, hacking those sites defrauds innocent people, hurts small businesses, provokes a legislative overreaction, erodes privacy, and just generally makes the whole web worse.

It's not worth it.

With that out of the way, we can move on to the first step in any bug hunting adventure: choosing what program to use, what site to explore, along with where – and how – to find vulnerabilities.

This chapter has covered the origin and benefits of bug bounty programs, the background knowledge you need coming in, an overview of some of the tools we'll use in our engagements, how to get the most out of this book (practice on allowed sites), and finally, the moral and legal peril you risk by not abiding by a target site's rules of engagement or code of conduct.

In the next chapter, we'll cover different types of bug bounty programs, the key factors differentiating them, how you can evaluate where you should participate, as well as what applications make good targets, where you should focus your research, and finally, how you can use a program's rules of engagement to minimize your legal liability as a security researcher.

1. Why do sites offer bug bounty programs?
2. What's the value in participating in them?
3. What do we need to know to get the most out of this book?
4. What are some of the tools we'll be using? What are they for?
5. How can we make XSS alert() calls more effective?
6. Is it OK to think about how a vulnerability could be exploited? How about writing code to test that theory?
7. What's the law governing much of the criminal theory surrounding penetration testing?

You can find out more about some of the topics we have discussed in this chapter at:

• About Open Web Application Security Project (OWASP): https://www.owasp.org/index.php/About_The_Open_Web_Application_Security_Project
• The 2015 UN Millennium Goals Report: http://www.un.org/millenniumgoals/2015_MDG_Report/pdf/MDG%202015%20rev%20%28July%201%29.pdf