xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Waite <m...@akuma.org>
Subject Re: xmlbeans xml security
Date Thu, 01 Jul 2004 21:48:13 GMT

On Jul 1, 2004, at 3:30 PM, Noah Campbell wrote:

> I'll assume that BEA's impl is not available for general consumption.

I dunno what BEA's impl looks like :)

>
> In regards to the current xmlstore, aren't the namespace names
> synthetic anyway?  I mean, you don't need to rely on the name except
> for its ability to link an element, etc to a namespace.  If someone is
> passing information through the namespace name then this might be
> considered a potential leak if full infoset is preserved.  This is
> probably contrieved and sorta silly but it is still something to
> consider.

In normal XML, sure. When you start canonicalizing xml, namespace 
prefixes matter, because qname types require schema awareness on some 
level to identify. If your canonicalized form allowed arbitrary 
prefixes to be chosen, someone could conceivably change the meaning of 
a document by putting a qname value in a different namespace.

The only real awareness of a schema or dtd used by canonicalization is 
expansion of attribute default types. I believe all the 'secure' 
messages (ws-security, saml) avoid default namespaces so they don't 
encounter this really ugly side-effect.

The issue is that when you parse in xml, it uses a qname and stores the 
namespace URI and the local name, but not the prefix. If you get a 
signed document in which declares a namespace both with a prefix and as 
the default namespace (perfectly valid) this breakage of infoset 
fidelity will cause the canonical form to differ where the saver chose 
a different namespace than was originally used, thus you will get a 
different hash out, and have very little idea what happened.

>
> (a silly side channel attack for example)
>
> <element xmlns:thePassphraseIsCheese="http://t.l.d/secureMessage">
>       <thePassphraseIsCheese:passphraseProtectedElement>
>                09832jkfadilafj#$@#rkfdali9fdalksdjf93aldkfja093ajfd
> <thePassphraseIsCheese:passphraseProtectedElement>
> </element>
>

Yes, fire the developer who did this ;-)

The issue is that the W3C allowed content to become dependent on 
namespaces, as if namespaces weren't tricky enough as is. XPath 
expressions and QName values in attributes and text nodes makes the 
namespaces important, as a transformation that changes the namespaces 
now needs to understand the context of the document which they are 
placed on. So while you could make a filter which replaced the prefix 
above with 'x0', it would need to know the schema, and would have to 
filter _after_ canonicalization and any validation associated (such as 
xml-dsig)

-David Waite


- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/


Mime
View raw message