« WS-WorldSeries | Main | Complexity Enemy of Web Services Security »



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.


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.

The comments to this entry are closed.