Today I came across an excellent slide deck on getting a shell through XSS by Hans-Michael Varbaek. Varbaek's presentation steps through the execution process from finding an XSS vulnerability, bypassing CSRF defenses, and ultimately uploading a php shell to a web server. After reading this deck, I started thinking about the previous "pen test" reports from external testers I've reviewed over the past several years. Many of these reports included XSS vulnerabilities. Invariably, what was presented for proof of the vulnerability was a screenshot showing <script>alert(1)</script> being provided to some input parameter and a popup box, or a close semblance of that. Of those reports, only one included a CSRF vulnerability even though our internal analysis showed that other CSRF vulnerabilities existed.
To be fair, this is not just a symptom of bad reporting by external testers or bad reports. Anybody who has performed pen testing and subsequently provided a report to a customer has experienced the response "What's the risk? How can this be exploited?"
As somebody who performs web app pen tests and writes reports, I've been guilty of providing the same example in the past. When discussing the XSS finding with a developers, they often didn't grasp the potential impact of XSS. Even if a CSRF wasn't possible, apparent defacing of a page through a reflected XSS certainly was. When I stopped providing a screenshot of an alert box and started providing a screenshot or POC URL for a page defacement, I immediately received a different reaction from both developers and their management. They could see the impact. Sometimes, of course, time limitations prevent me from developing a robust proof of concept. Whenever I can, I provide these kinds of examples in my reports.