A final word before moving on:
The techniques and technologies described in this book are solely for the purpose of participating in approved, ethical, White Hat penetration testing engagements so that you can find bugs and report them to be patched for a profit.
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 – 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 – it executes an alert() function within an improperly sanitized src attribute attached to an <img> HTML tag:
<IMG SRC=javascript:alert('XSS')>
There's nothing wrong with using an alert() or console.log() call to test whether JavaScript is being executed in a possible XSS instance – although, when using alert() or logging, it's good to remember to output some info about where the XSS is happening (for example, alert(window.location.href)).
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 –even in a limited way – 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 – 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 – how much damage you can make the case that an attacker could do – can drastically affect your reward.
So it's good to put some thought into the exploit's general form – with stored XSS, you could rewrite critical parts of the page where the script is being executed, or grab an authentication cookie and send it to a server listening for those credentials, or other attacks – but assessing the impact of that exploit still falls short of writing code that damages people and processes.
Don't write exploit code. If you're in the United States, the legal penalties are severe – as of this writing, the Computer Fraud and Abuse Act (CFAA) means that even a slight violation of a site's terms of service can result in a felony. Businesses are also quick to prosecute independent researchers not abiding by their rules of engagement, which is the condition researchers must follow when probing an application for vulnerabilities. Even if there's no threat of legal action, civil or criminal, hacking those sites defrauds innocent people, hurts small businesses, provokes a legislative overreaction, erodes privacy, and just generally makes the whole web worse.
It's not worth it.
With that out of the way, we can move on to the first step in any bug hunting adventure: choosing what program to use, what site to explore, along with where – and how – to find vulnerabilities.
