Last year I gave a talk on developing a working incident response program for small IT organizations at the ND IT Symposium.

Here's the summary:

-------------------
Your organization will be breached.  It's a matter of when, not if.  How you respond may be the difference between recovering and closing your doors.

This talk is designed to help small businesses or businesses with small IT organizations to develop a viable incident response program.
-------------------

The slides can be downloaded from slideshare here: http://www.slideshare.net/MikeSaunders4/you-will-be-breached-38429510


-MS

BSidesMSP Presentation - Problems With Parameters

Today was a first for me - my first presentation at a true security conference. The BSidesMSP crew put together a great conference with a lot of great volunteers. I'd like to thank both the crew and volunteers that put this together as well as the great sponsors that made this possible!  Plans are already underway for BSidesMSP 2015.  Follow @BSidesMSP or check out https://www.bsidesmsp.org/ for more details.

As promised, the slides from this presentation have been uploaded to Slideshare.  Feel free to reach out with any questions or comments.  The slides can be downloaded here: http://www.slideshare.net/MikeSaunders4/problems-with-parameters-b-sidesmsp

Beyond the alert box

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. 

It would seem that we as pen testers too often stop at the XSS. Varbaek's presentation should serve as rallying call to consumers of pen tests to demand better reports from pen testers. Those of us writing reports should accept the challenge to go beyond the alert box. Vivek Ramachandran of PentesterAcademy deserves a big nod for developing the Javascript for Pentesters course, which provides some great examples of how to go beyond the alert box with XSS.