XOM API for Processing XML with Java

[Adam Batkin <adam AT batkin.net>]

Wolfgang Hoschek wrote:
> On Dec 11, 2006, at 1:36 PM, Elliotte Harold wrote:
>
> > Jeff Williams wrote:
> >
> > > Gosh, I guess it's impossible to attack anything with XML in it. I'm
> > > going to upgrade my rainbow- and puppy-based security system to  
> > > "happy
> > > thoughts 2.0", now with XML.
> > It's certainly not possible to attack any real XML system by using  
> > CDATA
> > unless you can carry out the same attack without using CDATA.
>
> That's a claim with some adhoc reasoning behind it, but not anywhere  
> near a proof. Indeed, I'd be surprised if a credible proof emerged.  
> One day we could see the claim falsified by, say, a buffer overflow  
> exploit specific to CDATA in libxml or some other parser. Again, let  
> me repeat that this isn't about theory and "certainty" but about  
> practise:
>
> An "all or nothing" (e.g. either you let XML in or not) security  
> model is inferior to a multi-layered
> model (if layer 1 breaks, there's still layer 2 .. N left as
> defense). It's another way of saying that practical security isn't
> about making successful attacks impossible (you can't - get over it).
> It's about making them as difficult as possible. Talk to folks who
> run data centers.

Are you trying to imply that banning XML with CDATA sections inside can 
be part of a good multi-layered security practice? I think the point 
that some people were trying to make (and if they weren't, then I am) is 
that anything that can be represented in a CDATA section can be also 
represented in a non-CDATA section. If you ask me, that means that 
banning CDATA sections is silly.* For example, if you make sure to 
escape your <, > and &'s then instantly your regular XML can store 
anything that a CDATA section can store (or for extra obfuscatory 
goodness, add lots of numerical character reference entities. why not 
even encode entire text sections like that! I'd take a CDATA section 
over that any day). When decoded by a proper XML parser, the end results 
will be identical. So if you could sneak something bad in a CDATA 
section, you can sneak it in a non-CDATA section (with the added option 
of extra obfuscation).

* The exception to this is if the security person in questions knows of 
a specific attack vector involving CDATA sections (probably in a 
specific parser, say, an overflow only when handling CDATA). I highly 
doubt this.

That said, I think the whole argument about CDATA sections is a little 
weird since (as others have pointed out) the security people may have 
quite a bit of power to control things, and be living in a world of 
superstition...so why argue. Just properly re-encode what would have 
gone into a CDATA section and realize that what you get out at the end 
is identical.

-Adam Batkin