Hi Chad, > Second, the signature validation process could make available the nodes > that were covered by the signature and the application could check to > make sure those are the ones it thought were supposed to be covered. > This is more efficient but may require changes to the xmlsec APIs and > would require the application to a) know they had to do something and b) > actually do it properly.
This is already available via the JSR-105 API by setting the "javax.xml.crypto.dsig.cacheReference" property to true. Apache WSS4J uses this to build a set of protected element results, that can be subsequently compared to an XPath expression via WS-SecurityPolicy. It is up to the application calling the signature verification code to ensure that ID's are unique. The 1.5.0 release tightens this requirement by not searching the document tree for any IDs in "known" namespaces. The calling code must find the desired elements and register them on the context/IdResolver for signature validation to work. Colm. On Mon, Dec 19, 2011 at 6:10 PM, Chad La Joie <[email protected]> wrote: > Hey Colm, > > As I'm sure you're aware, there has recently been a set of papers > published that show various forms of attacks against XML > signature/encryption operations and one such attack was a signature > wrapping attack. > > While investigating this issue within our code we came across some > unexpected behavior with the resolution of IDs during the content > reference resolution phase of signature validation. In particular, > there was no check that IDs were actually unique. This allowed an > attacker to take a valid signature over some ID'ed content, create > malicious content with the same ID, and have our code report that the > malicious content passed signature validation. > > As part of trying to address this, I asked the Xerces folks if some > functionality could be added to the parser that would throw an exception > if multiple elements were registered with the same ID during parsing. > They said no. Such an approach would only work if content was being > schema validated during parsing so it wasn't a comprehensive solution > anyways. > > I do think it would be good if xmlsec did have a comprehensive solution. > As far as I'm aware there are two ways to implement such a thing. > > First, the IdResolver could walk the entire tree to ensure that the ID > was in fact unique. This is obviously expensive since it requires a > full tree walk but has the benefit of not requiring any API changes. > > Second, the signature validation process could make available the nodes > that were covered by the signature and the application could check to > make sure those are the ones it thought were supposed to be covered. > This is more efficient but may require changes to the xmlsec APIs and > would require the application to a) know they had to do something and b) > actually do it properly. > > I personally feel like the best approach would be to allow for both > options. Make the first option the default behavior but allow it to be > turned off if applications are willing to take on the extra work > necessary for the second option. > > On 12/19/11 11:18 AM, Colm O hEigeartaigh wrote: >> Here are some initial release notes for 1.5.0: >> >> http://coheigea.blogspot.com/2011/12/apache-santuario-xml-security-for-java.html >> >> Colm. >> >> On Fri, Dec 16, 2011 at 11:29 AM, Colm O hEigeartaigh >> <[email protected]> wrote: >>> All, >>> >>> A RC1 of the forthcoming XML Security Java 1.5.0 release is now >>> available. The distribution is here: >>> >>> http://people.apache.org/~coheigea/stage/xmlsec/1.5.0-RC1/dist >>> >>> The maven artifacts are here: >>> >>> http://people.apache.org/~coheigea/stage/xmlsec/1.5.0-RC1/maven >>> >>> Please test and let me know if there are any problems. I'll get some >>> release notes done shortly. >>> >>> Colm. >>> >>> -- >>> Colm O hEigeartaigh >>> >>> Talend Community Coder >>> http://coders.talend.com >> >> >> > > -- > Chad La Joie > www.itumi.biz > trusted identities, delivered -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
