Ethical Hacking and Penetration Testing Guide

Example 1
Location.hash is a very common source as well as a sink. Most of the DOM-based XSS I found 
did not escape the input passed via location.hash. Anything that is passed after hash(#) is not sent 
to the server as per the RFC; hence, the code gets executed on the client side resulting in a DOM-
based XSS, making server side defenses worthless. Also, from a forensic perspective, it becomes a 
great attack vector since the script executed on the client side won’t appear in the server logs.
One of the very common cases of location.hash source was found with several versions of 
jquery; the input passed via location.hash was not filtered out before it was reflected to the user. 
html5sec.org contains a list of vulnerable jquery versions:
◾
http://html5sec.org/jquery/
POC
http://ma.la/jquery_xss/#

---

380
◾ 
Ethical Hacking and Penetration Testing Guide
The Chrome JS console automatically points us to the vulnerable code as we were trying to 
load a nonexisting image (By clicking the line number, you would be automatically taken to the vulnerable code that is 
responsible for the cause of the vulnerability.
You can verify it by setting up a breakpoint on line number 7. The idea behind this is to gener-
ate an intentional error, which would get caught with Chrome js console, and hence point us to 
the vulnerable code.
DOM XSS wiki has a list of the best-known jquery sinks that would lead to dom XSS if the 
input is not escaped before being executed by a sink.
◾
https://code.google.com/p/domxsswiki/wiki/jQuery
Note
: This method does not work very well for inline JS, things such as 
eval() and set-
timeout()
. In such a situation, we can crawl the JavaScript for location.hash, location.href, and 
other input sources and set up breakpoints to inspect the input values on each of the breakpoints. 
For larger JavaScript files, this may be a tedious task; therefore, a better option would be to use a 
static or a dynamic code analyzer.