On 12/20/11 11:12 AM, "Sean Mullan" <sean.mul...@oracle.com> wrote: > >The code does still call DOM Document.getElementById, but how does that >make it possible to do an attack?
If you mark "known" ID attributes as IDs by calling setIdAtribute, Xerces will allow duplicates. If you insist that the application do a tree walk to prevent duplicates, then you're telling us that every app should implement the thing you claim is too slow for Santuario to implement. Additionally, parsers have bugs enforcing uniqueness on IDs during schema validation. Xerces-C for example has a nasty one involving wildcards and lax schemas. All because they allow something that shouldn't ever be legal in the first place, duplicates in the Document's ID map. Fix that, in one place, and all of this goes away. Thus my point. The Xerces team is wrong. Somebody needs to explain that to them, somebody they'll listen to. > The trusted validation code should be >creating the Document and registering the IDs. If you are letting >untrusted code create the Document for you and register arbitrary IDs, >then that is a bug. If you claim schema validation is "one way", then the parser has to be trusted. Alternatively, the application can't just register the IDs, but must also track and search for duplicates, or it can't rely on setIdAttributeNS to register them. That's why I'm asking about the algorithm. You're basically duplicating the DOM3 ID API in Santuario. So my advice is to stop relying on the original. Since I don't think that's really a good thing either, I continue to argue that the fix belongs in the parser. -- Scott
