A cross-site scripting vulnerability (also known as XSS) is a vulnerability that allows hackers to execute malicious scripts into a web application. Looking at the statistics of Google’s vulnerability reward program -Google rewards hackers for vulnerabilities they report to them- more than 65% of the vulnerabilities reported are XSS vulnerabilities.


The basic principle of an XSS is that you insert a payload which then reflects back to you on the same page, for example on your profile page. A blind XSS goes further than that. A blind XSS doesn’t reflect back to you, but it reflects back to systems like a CRM or a Server Administration panel. Since these systems are mostly designed to be used internally, they are not always developed with security in mind. This “No one can reach it anyway” approach, can for a hacker be a ticket to the “holy grail”.

If an attacker wants to exploit a blind XSS he needs to do three things:

This requires a couple of tricks. First you need to write a script that calls back to you when your payload is executed. This can be accomplished fairly easily. For example the script given below will ping the “log server” with the given domain-name and then execute the JavaScript parsed back by that log server onto the vulnerable web application. Doing this you can set-up an interactive shell.

This is an example code, for this to work you also need a working back-end to interact with the script.


By using JavaScript modules like for instance html2canvas it’s incredible easy to create screenshots of the victims application which could give a lot of insight about how the targeted application works and how you could exploit it further. Secondly, you likely want to view the HTML of the targeted page, and by using document.documentElement.innerHTML it’s possible to get the content of the entire page.

image is open.

As the XSS is likely executed on a device somewhere in a network, you could also use JavaScript to scan that infrastructure. You could run for example an IP range discovery or a port scan.

So, testing your internal (web)applications for vulnerabilities is also very important, even if they are not “reachable” from the outside. Because, as you can see above, they may be reachable anyway. It just takes a little bit more effort.