I’m not sure what your point is. Sounds like you’re saying that there’s no problem with it being a vendor-oriented presentation and I generally agree with that. My main contention here is that it was billed as “Techniques for Attacking and Defending XML/Web Services” and there are other ways to defend against these types of attacks that weren’t even mentioned. In fact, the solution to each vulnerability was “Deploy XML Gateway” which to me was more of a sales pitch for their product than a list of options for “Defending XML/Web Services”. I elaborated more on the other options in my initial comment. Anyway, I’m not going to debate whether it was or wasn’t too vendory, but it was the most vendor-oriented presentation that I saw at the conference. Thanks for your feedback.

~josh

Your comments are very useful and have initiated a serious strategic discussion within our company on how best to contribute to the community. Although Forum Sentry – our XML Gateway is available as a clean software install for (Linux, Solaris, etc.), we believe it may be time to carve out the XML Firewall capabilities and open source it. We are debating the commercial impact of this move, but generally feel it’s a win-win strategy long term.

In general, we think a security effort, commercial or Open source, should be decoupled from the application. The containers and parsers will continue to plug their holes, but as Ari mentions, it is very easy to crack a parser. Our security focus makes our parser better than others, and our focus is to rapidly fix any new and emerging issues that we see. By the time a bad XML packet reaches the back end, it’s already too late.

I like your recommendations – perhaps we should have called out some of the PHP built in functions that sanitize the SQL queries as code specific options along with other defensive coding techniques. Thanks for your honest feedback.

Regards,

-Mamoon

Thanks for your comments. I guess what I was trying to say is that maybe you could put a disclaimer at the beginning of your presentation saying “Hey, we know there are other options out there (SOATest, Service Test, Rational), but we’re demonstrating using SOAPSonar because it’s the one we’re most familiar with. If you need options, here they are.” I thought SOAPSonar looked like a pretty cool tool and even began the process of downloading it during the presentation so you’ll hear no negatives from me there. More options is all I was asking for to sufficiently make it less vendory.

As for the XML firewall, aren’t there software options there too? For example, I thought I saw Oracle WSM on the slide somewhere, but never heard you mention it. Basically, companies should have the ability to implement controls at the Application Server level rather than having to purchase an appliance, correct? You mention being able to code a defensive measure into an application. Perhaps some sample code to that effect would have been useful to illustrate? So we actually have three different options for XML security enforcement as far as I can tell: 1) Create the policies and embed protection directly in the application, 2) Create the policies as part of a software product like OWSM and have it intercept requests at the application server level, and 3) purchase a hardened XML firewall. Maybe it’d be worth spelling out those options and the advantages and disadvantages of each in future presentations?

All in all it was a very good presentation. Don’t let my comments on it winning my made up “Most Vendor-Oriented Presentation” sway you (or anyone else) from that fact. With web services and service-oriented architectures becoming more and more commonplace and increasingly exposed outside of the firewall, it is an extremely important topic and I was very happy to see someone talking about it. Thank you.

Sincerely,

Josh Sokol

For more information on recent XML vulnerabilities:

http://www.codenomicon.com/labs/xml/

Some example vulnerabilities:

http://www.codenomicon.com/resources/whitepapers/HH09-Takanen-Fuzzing.pdf

One test solution that is focused on XML fuzzing:

http://www.codenomicon.com/defensics/xml/

Thanks for attending the talk. We tried to keep away from mentioning product names in our presentation and really highlight the issues regarding XML/Web services security.

SOAPUI is a decent product, however, but lacks the pen testing capabilities and is generally considered a poor security testing tool. Most tools are first plagued with the problem of loading up a WSDL once it hits a reasonable complexity, let alone start functional or performance testing. For simple WSDLs, there are a number of tools that would be sufficient.

However, for serious performance, functional and security testing, SOAPSonar (Crosscheck Networks), SOATest (Parasoft), Service Test (HP) and Rational (IBM) tend to do a better job than some of the open source initiatives.

Also, please note that we do provide a free (albeit non-open source) version of SOAPSonar. Our objective is to create awareness about security issues and let the consumers select the tools. We would have used or mentioned SOAPUI if it helped address security issues.

For a user comparison of the product SOAPUI vs SOAPSonar.

As for countermeasure to XML security problems, one can either take the solutions mentioned in the context of an XML Gateway, such as Forum Sentry, or choose to code that defensive measure in an application.

There is no free alternative to XML security enforcement – either one re-creates the policies mentioned and embed the protection in the applications (consulting $$$) or purchase a hardened XML firewall (product $$$).

We look forward to contributing to OWSAP and making the community more aware of XML related issue and moving beyond the commodity HTTP stack issues that are fairly well understood.

Regards,

Mamoon Yunus
President & CEO, Crosscheck Networks, Inc.