Attacking XML Security

, Aug 15, 2007

A very interesting presentation for those who believe WS-Security will solve their problems. I’m no security guru, but this paper (PDF) would definitely make me feel uneasy had I bet my company’s safety on this … [via Steve Loughran]

On August 16, 2007 10:38 AM, Mike Glendinning said:


Well, I think many of us distrust the complexity of WS-Security.

And what Hill says resonates with me from my experience at T-Mobile in 2001.

I had many arguments with the T-Mobile “corporate security police” over my use of simple HTTP+SSL+BA to secure our external web services. But of course this gave us the all-important “accountability” as Hill describes whilst keeping things simple for the external content provider partners. This is what the business needed - the ability to recruit many hundreds of partners as quickly and cheaply as possible. In the event of any suspicious activity resulting from a particular content provider, we had the strongest contractual remedy - we simply wouldn’t pay them any money!

Take care though to understand Hill’s argument (in part 1) that client authentication is needed with SSL, so that you achieve the needed “accountability”. In my experience, client-side certificates are still too difficult for most people to understand and implement and since the certificate itself can be copied/stolen, provide you little extra assurance over ordinary passwords.

Also, in part 2, Hill criticises both XML-DSIG and XSLT, both of which might be part of many security schemes other than WS-Security. Personally, I avoid these simply because they are horribly ugly.

Finally, for the RESTafarians, isn’t there a problem in using SSL as this effectively precludes the use of intermediaries and cacheing? Aren’t these two features supposed to be essential parts of REST and some of the strongest benefits of plain-old-HTTP?


-Mike Glendinning.

On August 16, 2007 11:31 AM, Stefan Tilkov said:

Regarding SSL and caching, you are of course right. But you still get the benefit of client-side (if not intermediary) caching, and of course using multiple URIs for resources instead of a single endpoint (or small number of endpoints) allows you to decide whether or not to enable security on a very fine level.