This is the fourth post in our series: “Bug Bounty Hunter Methodology”. Today’s is a guest post from Scott Robinson, @sd_robs on Twitter and SRobin on Bugcrowd. Read on to learn how to write a successful bug submission. If you have any feedback, please tweet us at @Bugcrowd.

A guest piece by Scott Robinson

Submitting a bug to a company can be a tricky thing. As one might expect, security vulnerabilities are not always very straightforward- they might require multiple steps to reproduce, or utilize techniques that others aren’t familiar with. And when explaining steps to others, describing even seemingly simple concepts can be quite hard. An amusing example of this concept is a classic game in which the player attempts to instruct an alien on how to construct a peanut butter and jelly sandwich. The game ultimately ends with the “alien” player unintentionally misinterpreting the simple sandwich making instructions, and making a mess of the kitchen. While the consequences are not exactly the same when describing a vulnerability report, making assumptions or vague instructions can similarly lead to failure. With this in mind, let’s consider two key ideas to help you achieve this, and begin to perfect your bug reports:

  • Thoroughness. Make sure that you cover every single step that someone would need to follow to reproduce your bug. Will they need to be logged in to see it? Will it only work in a specific browser or is blocked by a content-secure policy? Is it clear which elements on a page you are referring to? If you have doubts about any of these, try walking through the steps yourself, and see if there are any steps that could be ambiguous. If you’ve put in a serious effort to achieve this but it still just doesn’t seem clear, attach a screen recording demonstrating the steps! Making sure the person reading your report is able to reproduce it is critical, and videos are one of the easier and most effective ways to achieve this.
  • Simplicity. While this may seem counterintuitive to the previous key idea, it is important to find a balance between thoroughness and complexity. While it may sometimes require a full page of steps to describe a bug, this is often not necessary. For example, reporting a reflected XSS (cross site scripting) may be as simple as providing a link and saying which browsers it will execute in. There’s no reason to include a stack trace or history of the web if your bug can be demonstrated by clicking a link!

If you can keep these two ideas in mind, then you’re well on your way to writing a good bug report. But the complexity of writing submissions is often more complicated than that- it’s not just about reproducing the bug, it’s also about conveying impact, and why your bug is important. This presents a separate idea, which can be equally as important:

  • Neutrality. Writing bug reports is more difficult than just helping somebody reproduce a bug; you’re also trying to properly convey the impact of the bug to them. But with monetary rewards involved, it can be difficult to provide an unbiased assessment of your bug’s actual impact. When in doubt though, just be honest! Presenting your bug to be worse than it actually is can lose trust with a company, and could even result in a lower bounty. So tell them exactly what your bug can and can’t do. For example, can your XSS potentially perform an account takeover? Why or why not? Providing escalated impact gives reasons for companies to pay you better, just be sure to provide appropriate proof!

Great, so now your report is thorough and straightforward, and its impact is clear. What else could you possibly need to make it better? Well, this last key idea is one that people often forget about, but arguably the most important:

  • Courtesy. For every report you write, there is always another human on the other side. In addition to managing your report, they have other responsibilities and hardships to deal with too. So give them some extra time before you ask for updates, and be understanding if they misinterpret your report the first time. Happy bug triagers can mean bigger bounties, so be patient and kind!

And that’s all there is to it! Now that you know the core ideas, go check out some awesome examples reports that utilize these ideas in this guest post by researcher Geekspeed.

Thanks for reading, and happy hunting! –Scott


TL;DR (too long; didn’t read)?

That’s okay! Just follow these 4 simple steps to perfect your reports from this point on.

  1. Be thorough. List all the steps someone else would need to produce your bug. Cover any detail that could potentially be ambiguous. And to be certain that your report is clear, include a video.
  2. Keep it simple if possible. Is it necessary to include a stack trace and video to demonstrate your stored XSS? It might be, but often times it isn’t! If so, don’t make the report unnecessarily complicated.
  3. Convey impact and do so in a neutral way. It’s important to tell the person reading your bug report why it matters. Just be sure to be honest about it, and show evidence if the impact is higher than what is obvious.
  4. Be courteous. There’s always another human on the other side of the report, and they have a lot to deal with as well. Use common courtesy when deciding if it’s appropriate to ask for an update, and be patient if they misinterpret your report the first time.

And that’s it!