Page 28 - Hands-On Bug Hunting for Penetration Testers

Joining the Hunt Chapter 1

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 d 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 d it executes an BMFSU function within an improperly sanitized TSD
attribute attached to an JNH HTML tag:

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

There's nothing wrong with using an BMFSU or DPOTPMF MPH call to test whether
JavaScript is being executed in a possible XSS instance d although, when using BMFSU or
logging, it's good to remember to output some info about where the XSS is happening (for
example, BMFSU XJOEPX MPDBUJPO ISFG ).

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 deven in a limited way d 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 d 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 d how much damage you can make the case that
an attacker could do d can drastically affect your reward.

[ 13 ]