Web Service Threats

I've been doing some work recently that involves enumerating the potential threats faced by SOA implementations. To help Google, here are a few of the resources I've found useful in doing so:

• ZapThink - XML Threat Management: As you'd expect of ZapThink, a good high-level description of XML threats in general, but no specific terminology for individual threats, and no categorisation of threats.
• Forum Systems - XML Threats: Forum Systems sell XML/web service security products, so as you'd expect they're hot on illustrating the risks associated with using Web Services to customers. Nothing like a rainstorm to sell umbrellas. This page provides a very high-level summary of the types of attack vectors used by malicious service consumers; a companion white paper, "Anatomy of a Web Service Attack" provides a lot of additional detail explaining these types of attack.
• ZDNet - Five things you need to know about Web services threats: A useful article by Scott Morrison, Director, Architecture and Security at web service security firm Layer 7. Gets away from talking about specific threats, and talks more about the goals and high-level approaches used by attackers. Well worth a 10 minute read.

Interestingly, there doesn't seem to be a consensus over a taxonomy (categorisation system) for these threats. Possibly the closest we get is in Scott's article, where he suggests that all web service threats can be put in three categories: API, Infrastructure and Transaction attacks. Sadly, Scott doesn't go so far as categorising the threats identified by the other vendors. Hopefully when this picture emerges, it'll represent industry wide consensus. This should allow vendors such as Layer 7, Forum Systems and IBM (with their DataPower range) to communicate with customers in a consistent manner, and allow them to sell their wares based on customer need and product capability, which after all is the key to long term relationships and repeat business.

After Service_1.0: The Service Interface Version Adapter Pattern

Stellan recently wrote an excellent article about dealing with the versioning of service interfaces. I thought I'd chip in with a slick way of dealing with the versioning of the service implementations themselves. To summarise his approach, Stellan talked about including versioning information in the namespace of your service interfaces, which as he says:

• Means that clients already using the interface won't 'break' the service interface.
• Allows service implementations (and clients, potentially) to dynamically determine the service version based on a message.

One further advantage that Stellan doesn't directly allude to is the co-existence of multiple versions of the same interface in the same runtime environment, which can be exceedingly useful, as I'm about to explain. Stellan explains in his article that the namespaced interfaces can be used on the server to route the message to either the latest and greatest or original versions of the service. Unfortunately, the side effect of that is that you have to keep maintaining two versions of the service, which is made even worse when you have some kind of underlying data store which has to be shared by both versions, because any structural change to that database will require you to modify the data access layer of every version of the service you currently have deployed. A little while ago, I came up with what I think is a nifty solution to this issue, which I called the Service Interface Version Adapter pattern. The pattern allows you to maintain total backward compatibility with clients, while only keeping one version of the service live. I'm sure I'm not the only one to arrive at the same answer, but I've never seen it documented anywhere. Basically, the pattern makes the assumption that version N+1 of your service is backward compatible from a functional point of view with version N. The interface can have changed beyond all recognition, providing it still possible to achieve the same result. Instead of keeping the old version of the service around, we introduce a transformation between the old version of the service and the new. If the transformation is simple, it could be implemented as an XSLT stylesheet, for more complex cases, bespoke Java/.NET/Python might be required, but it's complexity will be far simpler than the original service in the vast majority of cases. What's more, since there's now only one implementation of the service, clients calling the old version of the service will automatically benefit from bug fixes with no extra effort. Okay, so we now have one service implementation, but two working interfaces. What happens when we need to release version N+2? Easy: We add another interface version adapter which converts between version N+1 and version N+2. We could have achieved the same result by modifying the original transform to target version N+2, and introducing a new one between N+1, but if we had done that, we'd have to maintain an ever increasing list of transformations - back to square one. By just adding one new transform, the effort for each new version is the same: one new transformation. Clients of version N and version N+1 can continue to benefit from bug fixes, no matter how long they take to upgrade. Obviously, it'd be right to consider the performance implications of this. In reality however, most of the transformations involved will be so simple (add a default value here, move an attribute there) that even an XSLT based implementation will be fast (as long as you don't use DOM based transforms), so unless you're supporting 100s of versions, I don't believe it'll be a problem, and consider the alternative: 100s of fully fledged service implementations to maintain. If you're really worried about performance, and your budget can stretch to it, you could even consider implementing the whole pattern using an XML appliance like the 1U IBM DataPower which will do most of the heavy lifting in hardware. I have it on good authority that they are faster than an a flock of exceptionally fast things.