• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Craig Hays

  • About
  • Articles
  • Newsletter
  • Contact
  • Show Search
Hide Search
You are here: Home / Bug Bounty Hunting / Bug Bounty Hunting Tips #6 — Simplify

Bug Bounty Hunting Tips #6 — Simplify

May 11, 2020 By Craig Hays Leave a Comment

Reading Time: 6 minutes

Apply Occam’s razor to your bug bounty hunting. Cutaway all that is unnecessary. Reduce to the essential. Simplify to what is important and ignore the rest.

Bug bounty hunting tips #6 Simplify

On the surface, the web is a complicated place. For bug bounty hunters, most of it is just noise. A distraction from what is truly important. If you’re fuzzing inputs with an automated or semi-automated scanner, the more inputs and effective payloads you have to play with the more likely you are to find a bug. Otherwise, aim to simplify everything and manually test what remains.

Table of Contents

Toggle
  • Why You Should Simplify Requests When Bug Bounty Hunting
  • What Can Be Simplified?
  • An Example – A Simple Google Search
  • How I Simplify Web Requests
  • Identify Key Transactions
    • Common Headers and Cookies
    • Context-Based Guesses
    • Trial and Error
  • The Result
  • In Summary

Why You Should Simplify Requests When Bug Bounty Hunting

When you explore the web through a browser it makes tens or hundreds of HTTP requests for every page you visit, downloading HTML, stylesheets, javascript files, images, videos, and more. As an example, a simple Google search in a browser can take 58 HTTP requests to perform a single search and render the results.

A simple Google search takes 58 HTTP requests from start to finish in a browser

This is because modern web applications are bloated. Seriously bloated. If you look at the requests and responses of even the most basic web application, you’ll see numerous additional requests to private and third-party APIs, media resources, ad services and more. Each request is stuffed with cookies, headers, and parameters that add nothing to the functionality of the application. Analytics tracking codes, state cookies that are never used, unnecessary headers, and even input parameters from old code that no longer does anything. You’ll find it all.

While it makes the user experience much better, all of this noise makes it difficult to see what is really going on behind the scenes. If you’re testing for anything above the low-hanging fruit then gaining clarity and understanding of what is happening is key. Only by filtering out the noise can we hear the signal.

What Can Be Simplified?

As a bug bounty hunter, you’ll need to explore a web application with a browser to gain an understanding of what it’s trying to achieve. With that knowledge, you can reduce everything to the bare minimum components. I always try to reduce the following as much as possible:

  1. The number of HTTP or WebSocket requests to perform an action
  2. The number of headers, cookies, and input variables in each request

An action could be anything from a 1-click password reset email, to completing a 7-page, stateful, web form with client-side and server-side state manipulation. How you classify a single action isn’t important. It’s about asking ‘what is the bare minimum I need to do to achieve X’.

An Example – A Simple Google Search

A Google search for my name (vain, I know…) should be simple. In theory, it only needs two things: the search query, ‘Craig Hays’, and a call to the action to perform the search. The reality is that for brand new, unauthenticated users, a simple Google search looks like this:

Note: I’ve redacted anything that looks like a token as I expect you’re just like me. Even though I did this in a disposable user profile, I’m not taking any chances

Look at all of those headers, URL parameters, and cookies! I can strip away almost all of that and still get a valid response. In fact, I only need two lines in order to get an answer.

The rest of the request is about tracking what you’re doing and formatting the response from the server. You can do this with almost any application online. 90% of the content in each request can be dropped without problems, if not more.

How I Simplify Web Requests

My approach to doing this is equally as simple.

Identify Key Transactions

The first thing I do after running through an action a couple of times in a browser is to manually review each of the HTTP requests from the Burp HTTP proxy log and identify those that match what I was doing. If it was a search, I look for the completed search terms. If I completed in a form, I look for the form data. You get the idea.

If it’s not obvious by looking in the proxy logs, I switch on intercept mode and watch the requests in real-time as they are made. If I still can’t work it out, I start dropping requests out of the process until it breaks, then I repeat until I’ve removed everything I can. The majority of transactions are just a single HTTP request with a few analytics or media requests either side. It is less common for actions to require 2 or more distinct, client-less requests unless a redirect is taking place.

Common Headers and Cookies

With the smallest number of HTTP requests possible, I send each request to Burp Repeater for per-request simplification. First I strip out all of the things I recognise as common headers and cookies that are present on most sites. With experience, you quickly realise that any ‘_ga=GA…’ cookies are Google Analytics tracking codes and the application works just fine without them. JSESSIONID, on the other hand, is a java generated session identifier and without it, the app may not remember who you are.

An ‘Authorization: Bearer’ header will log you out if removed (or it should). Cutting things out is also a valid form of security testing. If you remove all of the session cookies and you can still access a resource, that’s a bug. If you take out the CSRF token and it still works, that’s probably another bug. There’s value in cutting away the excess beyond the outcome. With simplicity comes understanding and insight.

Context-Based Guesses

Based on the names and values of each Key: Value pair in the request, I take a guess at what they probably mean. For example, looking again at the first google query:

  • GET /search?source=hp – I’m pretty sure that hp stands for homepage as I just came from there.
  • &q=Craig+Hays is a short form of &query=<the think I just typed>
  • &oq=Craig+Hays is the original query I typed and Google didn’t feel a need to auto-correct for me
  • gs_lcp is probably Google Search something, something, something…

As I go through each one, if it doesn’t look important I strip it out, retesting each time in Burp Repeater.

Trial and Error

Lastly, I simply remove headers, cookies, and parameters one by one until the application breaks then I put the required parameter in. Every breaking change tells me more about the way the underlying application works. Anything that doesn’t cause an error wasn’t needed and can be disregarded completely from future testing.

The Result

At the end of this process I have the following:

  • The Minimum Viable Interaction required with the web application to achieve the desired outcome
  • A greater understanding of how the application works and which inputs do what
  • A smaller, more focused attack surface to test against
  • The option to add back in what was stripped away to test the effects of changing one variable at a time.

In Summary

Use this technique as another tool in your toolkit but don’t feel like you need to do it all of the time. There’s nothing wrong with testing in depth. You’ll miss simple bugs if you never look at the bigger picture just as much as you’ll miss deep bugs if you never narrow your focus. Strip away what isn’t essential to learn the minimum inputs for an application and use that knowledge in the rest of your testing. If you toggle inputs you’ll reach a level of understanding where you could code the application yourself from scratch. That’s the true goal of what we’re aiming for here.

View other posts in the Bug Bounty Hunting Tips series

Filed Under: Bug Bounty Hunting Tagged With: bug bounty, bug bounty hunting, bug bounty hunting tips, bug bounty hunting tips series

Newsletter

Want to get smarter about cyber security? Join my growing list of newsletter readers for exclusive news, reviews, how-tos, and more.

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Newsletter

Want to get smarter about cyber security? Join my growing list of newsletter readers for exclusive news, reviews, how-tos, and more.

Craig Hays

© Craig Hays, 2006–2025

  • All Articles