Page 177 - Hands-On Bug Hunting for Penetration Testers

Formatting Your Report Chapter 10

Reproducing the Bug ` How Your

Submission Is Vetted

Without the internal security team being able to validate your findings by recreating your
PoC, it's hard to get a reward. You could've spoofed or mocked up findings, or created
them during some since-patched edge condition that doesn't represent a significant threat.

The easiest way to ensure that your bug is reproducible is to, from the very beginning,
practice reproducing it yourself. If it's a manual finding or semi-automated tool such as
Burp Intruder, can you reliably recreate it (it might take a couple of tries to get the right
sample size if there's a race condition), and if it's from the tightly-controlled application of a
scanner, can you recreate it manually? It's not enough to run the scan again and see the
same results, if you can't recreate the automated vulnerability manually, it will be
dismissed as a submission.

Writing up a series of reproducible directions is easy if you stress the right things. You
should be careful to:

Use clearly numbered steps.
Add a succinct description and screenshots of the app state at each step.
Note any in-app side effects, even if they're functional issues and not directly
exploitable (for example, User info modal opens and closes immediately) because
they might clue in the responding developer to an issue you're not aware of, and
tell them they're on the right track.
Include fine distinctions (clicking the submit button versus highlighting the
submit button and hitting return) to provide as much useful context as possible,
without going overboard. A good question is: are you rewording vague
descriptions to be as specific as possible (good), or are you typing a stream-of-
consciousness jargon salad, throwing every piece of information or data point at
the wall to see what sticks (bad)?
Beyond the descriptive quality of your reproducibility walkthrough itself, it's
also important to include (useful) context about your environment that might go
deeper than the Methodology section. For example, in Methodology, you might say
I navigated to X page and filled the Y input with Z value, before using such-and-
such tool. Some extra, useful context would be your browser type, version, and
any applicable extensions or configurations that distinguish it. Unnecessary
context might be that you also have a game installed on your system that's
completely removed from any of your testing findings.

[ 162 ]