WS-Insecurity

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.

An OWASP for Enterprise Architects?

.... now there's an idea. From http://duckdown.blogspot.com/2009/01/what-does-would-could-attend-it.html:

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.

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:

{Three Letter Acronym} is Dead

The current discussion around Anne Thomas Manes' blog post that SOA is Dead (http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html) reminds me of another Three Letter Acronym which was declared dead. Back then, eight years ago, it was PKI which was declared dead. There are similarities with SOA. In the case of PKI, there was a tendency towards what in France are called "grands projets", ie large complex deployments. The "full blown PKI", with its CA, RA, hardware stores, etc etc, was a classic example of this. Banks and governments were seduced by this, and often built out architecture for the sake of architecture. What was missing from PKI? The focused applications. It is hard not to see the analogy with SOA "grands projets", complete with UDDI, etc.

In the meantime while PKI was being declared dead, VeriSign had created their own PKI in the "cloud", (which they never called a PKI). Savvy organizations started to focus on the applications (chiefly SSL) and outsourced the PKI itself to the Cloud (VeriSign) to deal with key issuance, certificate expiry management, etc. VeriSign did very well out of this. While "PKI" became a dirty word, VeriSign prospered with a cloud PKI. Who is the VeriSign in the SOA analogy? Amazon. Without ever calling their services, or indeed their services hosting platform, an "SOA", they have build the successful SOA in the cloud.

And what is the equivalent of SSL, ie the simple and useful application of the techhology? The answer this time is REST, SaaS, and the direct EDI-style XML messaging which we have seen many Vordel customers successfully use.

By the way, whatever about SOA, I don't agree that SOAP (and the many WS-* technologies) is dead. *building it from scratch* is dead, but any glance under the hood of Microsoft .NET shows it is very much alive and is becoming more and more a core part of Windows (just as Microsoft build PKI into Windows server products quite successfully and quietly). And it is not a case or "either / or" SOAP or REST: XML Gateways (such as Vordel's) do a very successful job of mediating between the two.

Like PKI, the "grands projets" approach to SOA is dead. But that opens up the opportunity for focussed applications, for cloud providers, and for XML Gateways which, through protocol mediation, make the "SOAP vs REST" debate moot.

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].