I was doing some thinking on the most common places you are likely to find XSS vulnerabilities - in particular reflected XSS vectors that take URL parameters. Of course, the first thing that comes to mind is error conditions, like “Cannot find ….”. That’s probably obvious, of course and maybe there’s room to have a custom error reporting function that deals with the problem better than simply outputting text to the page, but that’s less interesting than my next thought.
The other place I have seen this type of vulnerability is in custom 404 scripts. One example was the UTF-7 exploit found in Google’s custom 404 script. One of the great things about custom 404 scripts is that they are incredibly easy to locate, if they exist.
A simple scanner that simply loads up a list of websites and/or IP addresses could work through a huge list relatively quickly, outputting a potentially huge list of vulnerable XSS reflections.A simple script testing for a function like http://www.example.com/<XSS> or one of the other payloads on the XSS Cheat Sheet that then watches for return output looking for the same thing outputted could be far more efficient for finding large swaths of vulnerable websites than by-hand auditing could. Of course this would miss a huge percentage of vulnerable applications, but for a spray and pray approach, this would be far more effective than most other methods. This could also have huge implications for the Blackhat SEO community.
I’ll talk about other (and arguably better) methods of doing large scale XSS vulnerability assessments at a later date, but I did want to get this out there.