Attacking WS-Security
Steve Loughran posted briefly on the presentation Attacking XML Security. It's a really interesting slideshow, and I wish I'd seen the entire talk. Brad Hill starts with a brief defense of SSL/TLS and connection oriented security. Brad then examines WS-Security starting with the threat model, or more importantly, the implied threat model, namely the 4th dimension of accountability. One's business partners don't generally try to rip one off, so the concern is not really with authenticated attacks such as the typical things like SQL injection. Brad's point is that the security concerns are now the following
- The attack surface is now WS-Security, but a lot of software is involved in getting to that surface - XML Parsers, protocol handlers, etc.
- SOAP applications are generally not message oriented - the services are often not truly stateless and sensitive to message ordering, replaying, etc.
- The security and application layers are tightly coupled.
- WS-Security is just too complex and hard to get right.
In my experience as a client of services using, WS-Security, that last point is dead on. It can be really difficult to just get access to these services.
The second part of the presentation focuses on attacking WS-Security. Much of this focuses on the complexity involved in determining which parts of a message to sign and verify, and the pitfalls involved, though he also spends some time talking about the problems with messages that refer to external documents, and also pitfalls with XML Digital Signatures in general. It's almost like saying that WS-Security isn't bad, per se, but rather that it depends on a number of flawed technologies.
I'm not sure that the flaws he mentions with digital signatures are issues for applications like syndication, but leaves me with a general worry that the flaws Brad points out will pose a problem for any 2-way messaging protocol that wants to build non-repudiation into the messages. I'm satisfied that SSL is in fact the best solution for transport-level security, but what about the application layers? Also, Brad advocates private certificates for SSL, which should work for B2B scenarios, but are probably prohibitive for public APIs.