Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XOM-interest Digest, Vol 47, Issue 5

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Adam Batkin <adam AT batkin.net>
  • To: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XOM-interest Digest, Vol 47, Issue 5
  • Date: Tue, 12 Dec 2006 08:01:55 +0000

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






Archive powered by MHonArc 2.6.24.

Top of Page