There was a great presentation at Black Hat recently by Brad Hill of ISec Partners on Attacking XML Security. It says something about XML Security attack surface that this talk extends to 182 content-rich slides without even having to mention attacks such as sending unexpected signed SOAP Attachments, or embedding a bogus Schema Reference in a signed XML message.
There was a lot of really good content in Brad Hill's talk, but I'm going to concentrate on one thing in this blog post.
The talk pointed out that most implementations of XML Signature try to validate the signature before verifying the trust of the signer.When I saw this slide, I thought "YES!": 
A reasonable person may ask: Surely it is common sense to check the trust first? Imagine a physical security analogy. Let's say a bulky package is dropped off by a courier at a government agency. Do you (a) check if the sender is trusted first, before even considering opening it?, or (b) go ahead and open it, before checking the identity of the sender? Of course, you do (a). And even if the sender is trusted, you may still scan the package anyway. But, at that point, you have cut down the anonymous attack surface.
The reason why so many XML Signature implementations do signature validation before they check trust goes back, as Brad Hill mentions in his talk, to the original foundation of XML Signature. Here is a link to a really useful post by Joe Reagle on the XML Signature mailing list in 2002. In the post, Joe Reagle contrasts the words "validate" and "verify", referencing the IETF Glossary. To check that the XML Signature is a "good" XML Signature, you validate it. Part of this validation can (depending on the implementation) introduce the vulnerabilities which Brad Hill documents. But, checking that the signer is trusted is something else entirely, since that is to verify the signature. Why make the nit-picky difference? The reason is that, as Joe Reagle also points out in his post, "xmldsig ruled trust out of scope". Naive implementations of XML Signature simply implement what is there in the specification, without realizing that trust is also important. This is validate then verify. Checking the structure of the XML Signature before checking the trust.
By checking the trust first, as in Brad Hill's slide above, you're doing verify then validate. You are greatly reducing the anonymous attack surface (something Brad Hill talks about early in his talk. If you validate first, you are potentially wasting XML Signature validation processing on messages from client who are not even trusted. And, like the package in the physical security analogy above, this can blow up in your face.
4:15:10 PM 
|
|
