On 12/20/2011 11:06 AM, Chad La Joie wrote:
On Tue, Dec 20, 2011 at 10:55, Sean Mullan<[email protected]> wrote:
It no longer searches. All IDs have to be pre-registered. It knows about IDs
in the XML signature namespace so pre-registers those itself.
I guess I'm missing something. How is this done? After a parse
(without schema validation) no attributes would be marked as ID
attributes. So how does the library "pre-register" anything?
It has builtin knowledge of the XML Signature schema, so it is able to
register all elements with ID attributes in the dsig namespace as it is
parsing the XML Signature. If there are any duplicates, as of 1.5 it
throws an exception.
And are
you saying that prior to signature validation (or encrypted key
resolution), that the app must go through and register every
ID/element mapping itself?
Just the ones that aren't in the dsig namespace. We don't have any
knowledge of other schemas. I'm not sure about the enc namespace, will
need to check that.
We could search the entire document every time for duplicate IDs but then
nobody would use the library because it would be too slow.
Not to be flippant, but do you actually have anything to back that up?
Relatively speaking, a treewalk is pretty fast (when compared to
things like canonicalization and various crypto functions).
We used to do a recursive walk of the tree every time to fix namespace
attributes when canonicalizing to workaround bug 2560 in Xerces - the
code is actually still in there - search for circumventBug2560.
I remember that when we removed the dependency on this method, there was
a performance improvement, how much I don't recall but it was somewhat
significant if I remember - these numbers could be in the archives
somewhere, when I have some more time I'll check.
I would want to do some performance testing before we added something
like this.
This is an issue that we can solve partially, but in my opinion higher level
APIs need to also do their job and register the IDs in their own namespaces
(or use a validating schema). Then wrapping attacks are not possible.
Sure, and everyone should always completely bug free code. They
don't. All I'm trying to say is that we could provide a real fix for
this that protects people against an attack that is known to be in the
wild and which all tested users of Santuario were vulnerable to.
Ok, I can see how this could make things easier and help screen out
potentially dangerous documents. Would you have some time to writeup a
patch that we could then do some more testing on?
--Sean
