Thursday, January 29, 2009


Gunnar Peterson and Brian Chess gave a talk at RSA last year about how WS-Security is often used in an insecure manner. This drips with irony since WS-Security is, of course, a security standard.

Gunnar writes:

Next, unfortunately saying you are using WS-Security doesn't mean all that much. As Brian Chess and I talked about in our RSA talk last year, the spec leaves ample room to shoot yourself in the foot at design time and that's even before you get to implementation. You can use weak token types, lack integrity, open up information disclosure, replay and a host of other vulns, all while still being WS-Security compliant, depending on the profile.

Consider the scenario where WS-Security is being used encapsulate X.509 Certificates as a means of "authentication", but without any associated signature, nonce, or timestamp. This means that anyone with access to the client's public key could access the Web Service. Basically the client is saying "Here is my X.509 Certificate, let me in". And, the X.509 Certificate is publicly available anyway. Sending it in a WS-Security message proved nothing. I saw this scenario recently (and explained why it was insecure!).

The scenario of "We will let messages signed by a trusted client into our Web Service" is frighteningly common. You may ask "Why is that bad?". The answer is that anyone who can get their hands on a signed message (e.g. from log files) can replay the message through, and get the response. There are *many* such "roll your own" use cases of WS-Security out there. And, in 99% of cases, the recipient is only checking the signature over the SOAP Body, not over the routing information (leading to a routing-based attack by an attacker inserting a bogus "ReplyTo") or a creation/expiry times (if these are even present).

When I give training on this, I always recommend that people look to the WS-I Basic Security Profile, not directly to WS-Security. The WS-I have profiled how WS-Security can be used in a secure and interoperable manner.

An additional problem with WS-Security is its name. It leads to the assumption that the usage of WS-Security makes a Web Service secure. However, you can have a Web Service which is using WS-I compliant WS-Security, and receives a signed, encrypted, authenticated message from a trusted client, only to be hit by a SQL Injection attack, a virus in an attachment, or a DTD-based "XML Bomb" attack.

PS: My own view on why WS-Security is gaining usage is because (a) XML Gateways make it easy to deploy WS-Security without writing code, and (b) the Microsoft WCF (plus Geneva, etc) make extensive of WS-Security within their messages. But it's the "roll your own" solutions I'm worried about.

Monday, January 26, 2009

An OWASP for Enterprise Architects?

.... now there's an idea. From

    Or, perhaps a no-frills approach? Bring your own lunch? Hosting a small gathering at your organization? Other ideas?
Well, this at some level feels a lot like OWASP where conferences are only $400 instead of thousands as they have cut out lots of the frills. Likewise, they also offer local chapter meetings which are free to attend.

Wednesday, January 21, 2009

Vordel's new YouTube Channel

Check out Vordel's new YouTube Channel, including Screencasts about XML Gateways, Identity Federation, Security Token Services, and Service Virtualization:

Tuesday, January 6, 2009

Welcome to the cloud

Sreedhar Kajeepeta, Senior VP and CTO of Covansys (part of CSC) has written a great introduction to Cloud Computing in Software Magazine . He charts the early days of Cloud Computing with Google and Amazon, and looks to the future where IT executives can "begin to take computing power for granted, just as they do their electric power". Sreedhar gave a great talk at Vordel's conference in September, and he's a great thought leader to follow in this area.

One missing piece in Cloud Computing is the client side. How can businesses connect up to the cloud without fear of loss of network connectivity, or fear of information disclosure? The Cloud vendors concentrate, as you would expect, on their own infrastructure, and shy away from supporting infrastructure on the client side. It's up to clients to figure out how to connect up to Cloud services, which is fine if they have an internal development team which can use the APIs. But what if they don't? And what if they want to cache traffic in case the connection to the Cloud is unreliable? What if they want to ensure that the data being sent up to the Cloud Computing provider does not include private information which should not leave the corporate network? All those questions have yet to be answered [but, hint... Gateway technology is an answer].