App Security at QCon

The first App Security track is in full swing at QCon. I have to hand it to the folks at InfoQ and JAOO, they might be the first big development conference to take a real shot at doing a full blown app security track. Right now, Jeff Williams is presenting an Enterprise Security API (sorely needed for consistency and integration), which is slated to be released next week at OWASP's conference. The slides for the App Security track are all being added to the QCon site.

Kent Beck did a keynote and two of the main points he stressed were developer accountability and transparency. This was a perfect lead in to Brian Chess' presentation on static analysis, which remains one of the cost effective and scalable app security tools we have.

Next, John Steven presented some advanced threat modeling techniques, because this is a developer conference in 2007 most people haven't done threat modeling so it was a learning experience with a lot of real world q&a. The responses from developers who heretofore have not focused too much on security has been really positive which is nice to see.

There have been some great sidebar conversations. There are a lot of agile disciples here (of course), and they are somewhat concerned about how (and how much) security to add in to their process. This gave me a chance to reference one of my favorite papers of the year - Johan Peeters and Paul Dyson's paper on Cost Effective Security, which sorts out app security concerns in an agile way.

Comments

[dre]

InfoQ is great, and your presentation about re-balancing the security investment is top-notch! Where is your other presentation available? I am very interested in talking to you about continuous integration - I guess I missed you when I spoke at OWASP MSP last month where I spoke about that topic.

On slide 47 of your "SOA and Web Services Security" presentation, you provide links to some web services vulnerability assessment tools.

The iSecPartners WsBang is a great tool, as are the Net-Square ones (however, I believe Shreeraj Shah is now hosting his content and tools from the blueinfy.com website, where wsScanner - http://blueinfy.com/tools.html - can instead be downloaded from).

The OWASP WSFuzzer - http://www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project - code is over a year old now, and doesn't look like it's being worked on anymore. The SIFT - http://www.sift.com.au/73/171/sift-web-method-search-tool.htm - tool is also interesting and worth a look. I also can't figure out what happened to WebServicesStudio from gotdotnet... many of these tools are so outdated.

Which is why I was so surprised to see a new (well, new to me) tool, SOAPSonar, demonstrated at VERIFY 2007 conference last week. I have recently downloaded the free Personal Edition, but the Enterprise version (which supports PKI and Vulnerability testing) costs $799. CrossCheck Networks, who makes SOAPSonar, has an interesting article on SOA testing - http://www.crosschecknet.com/soa_testing_black_white_gray_box.php - that mentions how the XSD-Mutation and other aspects of the vulnerability mode work.

The presenter, Kiran Chittargi - http://verifyconference.com/content/view/120/26/ - did a great job, IMO - it was one of the best technology demonstrations I've seen during a presentation lately.

Much of the support for web services security testing in the commercial web application vulnerability scanner world is about as good as W3AF or WebScarab. There are very few point tools, so SOAPSonar really sticks out to me as a winner in this field of security testing. I would expect that W3AF will emerge to be superior to all the other tools currently available, not only because it's one of the only ones being actively worked on, but also because the author of http://w3af.sf.net is also the author of http://untidy.sf.net, an XML fuzzer.

[dre]

Oh I forgot about Interceptor - http://www.owasp.org/index.php/Category:OWASP_Interceptor_Project - which also hasn't been updated in awhile, but also worth a look for assessing XML and Web Services. I find it interesting that this tool claims support for both Web Services and Ajax, which of course both utilize XML.

Speaking to Ajax, there are still very little commercial or open-source scanners or vulnerability assessment tools available. Using a few SQA tools or libraries, you can easily roll-your-own Ajax scanner (e.g. RBNarcissus, FireWatir, Watir, Watin, Watij or even something like scRUBYt). The only true assessment tool is FireBug (the only tool mentioned in my Rough-Cuts copy of Ajax Security by Billy Hoffman and Bryan Sullivan). Certain other open-source tools such as w3af or scanweb2.0 (from Blueinfy, which includes Ajaxfinger, Scanajax, Scanatlas, and Urlgrep) can also be useful. Sprajax from the denimgroup/OWASP is somewhat helpful - as are the commercial scanners that support Ajax (Cenzic Hailstorm and IBM/Watchfire AppScan support it fairly natively, while HP/SPIDynamics WebInspect supports it in a similar way as w3af or Urlgrep).

Some argue whether or not Ajax / Web 2.0 even adds new attacks (including what you said here - http://1raindrop.typepad.com/1_raindrop/2007/04/fortify_finds_w.html)

In the October survey by Jeremiah Grossman - http://jeremiahgrossman.blogspot.com/2007/10/web-application-security-professionals.html , one of the survey comments about whether or not Ajax adds "new attacks" or simply "increases the attack surface" added some new light on to the matter for me. I voted for "A few more attacks", but this commenter said, "Javascript Hijacking wouldn't exist without JSON. User tailored JSON responses would be rare without AJAX" which makes me want to change my position on the matter somewhat.

If Javascript-Hijacking is only possible with JSON and not XML (so far this remains true), then the problem isn't really Ajax or Javascript, it's more of a CSRF issue in JSON. For finding CSRF there is little help other than using a CSRF Redirector - http://shiflett.org/blog/2007/jul/csrf-redirector or possibly CSRF dorks - http://csrf.0x000000.com/csrfdb.php , so for JSON Hijacking it would be very similar in concept.