The book Real-World Bug Hunting by Peter Yaworski is a field guide to finding software vulnerabilities. It explains what ethical hacking is, explores common vulnerability types, explains how to find them, and provides suggestions for reporting bugs while getting paid for doing so.
InfoQ readers can download a sample of Real-world Bug Hunting .
InfoQ interviewed Peter Yaworski about ethical hacking, HTTP parameter pollution and HTML injection, SQL injection and the protection that content management systems are offering, OAuth vulnerabilities, and writing better bug reports.
Peter Yaworski: When I became interested in internet security, I couldn’t find an easily accessible resource to walk through everything I "needed" to know. Instead, I was combing through blog posts, open vulnerability reports, conference presentations, etc. to learn everything I could.
During this process, I realized two things; first, I found the materials I was reading were usually complex and dense. Second, for me to retain everything I was digesting, I needed a system to do so. As a result, the first iteration of this book was born as a self-published project of thirty vulnerabilities, which I explained in plain language. The goal was to teach others as I learned as well.
Yaworski: It’s written for beginner hackers, no matter their background. I tried to write it as the resource I wish I had when I started out; something in plain language but that still covered complex concepts. While I think it helps to have some programming experience, the book covers topics assuming no prior knowledge. My publisher No Starch was instrumental in achieving this. I can't say enough positive things about their attention to detail.
Yaworski: To me, the simplest explanation as it relates to computer security is identifying vulnerabilities and responsibly disclosing them to application owners with positive intent. In other words, finding bugs and letting developers know about them with no malicious impact. But that said, as it applies to computer security, I think everyone needs to recognize when this is accepted or invited behaviour, versus testing anything and everything you can find under the guise of positive intentions.
Yaworski: As explained in Chapter 3 of the book, HTTP parameter pollution is the process of manipulating how a website treats the parameters it receives during HTTP requests. The vulnerability occurs when an attacker includes extra parameters in a request and the targeted application trusts them, leading to unexpected behaviour; in other words, if you visited a website with a url which included ?user_id=1 and you added &user_id=2 , such that the url you visited was now ?user_id=1&user_id=2 . When performing such testing, you’re looking for unexpected results or unintended behaviour which an attacker could leverage to their advantage.
This type of vulnerability is prevented, like most in the book, by strict input validation; checking that the input received matches what is expected, versus blindly trusting attacker controlled input.
Yaworski: HTML injections allow attackers to manipulate the look and feel of a website. One reason for doing so is to trick people into sending sensitive information to an attacker-controlled website. A typical example includes rendering a web form which looks legitimate but actually sends the values it receives to a third party server. As a result, a targeted user may visit a website with an HTML injection vulnerability, be presented with a login page looking like it belongs to the application, but when clicking "Log In", the username and password provided are actually sent to a third party server for a malicious purpose.
Yaworski: The impact of an SQL injection vulnerability really depends on the information that a database contains. In the best case scenario, no harm is done because the database includes no sensitive information and is properly isolated for other sensitive systems. In the worst case scenario, SQL injection can be devastating if an attacker has access to extract large amounts of personally identifiable information, they can create administrative accounts for themselves on the application or can read local files from the server. An example of this is covered in the book: a SQL Injection in Drupal version 7 from 2015, which allowed for privilege escalation, arbitrary PHP execution, or other attacks depending on the configuration of the application.
Yaworski: Content management systems and other development frameworks are only as secure as the developers creating web applications with them. It isn’t hard to introduce SQL injection vulnerabilities if you are mistakenly adding user controlled input to SQL statements. But that said, content management systems like Drupal and Wordpress and frameworks like Ruby on Rails do a great job of making it harder to introduce the vulnerability. Like all software, they can introduce their own vulnerabilities too, but the security teams for all of these open source projects need more credit for the work that they do and value they provide.
Yaworski: From what I’ve seen, the most common causes of OAuth vulnerabilities result from a lack of strict validation on the redirect_uri parameter, failing to validate the state parameter and failing to validate token scopes. To prevent these issues, developers should:
Unfortunately I only cover stealing OAuth tokens in the book and do not cover exploiting guessable state parameters or validating tokens.
Yaworski: When you’re starting out on a bug bounty program or voluntary disclosure program, always read the programs rules and policies. This ensures you are adhering to their requirements and not performing any inappropriate testing. Once you’re familiar with what the target is allowing, be conscious of how your testing may impact the application or other site users. You should never impact other legitimate site users; this is often stipulated in program policies.
If you’ve managed to discover a vulnerability, write the report as if the recipient is unfamiliar with the system you’re testing. Including the necessary details will ensure the recipient is able to reproduce the error and can share the details with the necessary developers as soon as possible. Omitting details could result in the recipients being unable to validate your report and cause unnecessary lost time going back and forth with questions and answers.
When you begin submitting reports, recognize that doing so is actually building you a reputation within the information security community, if not just the bug bounty community. Your reports could become public and will represent you so you should always write and submit them with that in mind. Lastly, always practice empathy for those receiving reports and developing fixes. Everyone wants the internet to be safe, so assume positive intent and work collaboratively.
Yaworski: YouTube conference videos are a great resource; Blackhat, Defcon, Bsides, Northsec, Hackfest, etc. are all great examples. Twitter is a resource I rely on to find the most recent blog posts. Additionally, HackerOne’s hacktivity continues to be a wealth of knowledge from bug bounty hackers. I’ve begun transitioning my hacking resources to github.com/yaworsk/bugbounty which I use to record the blog posts, resources, write-ups, etc. I read and learn from. No Starch is also publishing a lot of great content on hacking, including Attacking Network Protocols, Practical Binary Analysis and the upcoming Blackhat Go.
Peter Yaworski is a successful bug bounty hacker with thanks from Verizon Media, GitHub, Salesforce, Twitter, Airbnb, and the United States Department of Defense, among others. He currently works at Shopfiy as an Application Security Engineer, helping to make commerce more secure.