Skip to Content.
Sympa Menu

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

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Harold <elharo AT metalab.unc.edu>
  • To: Jeff Williams <jeff.williams AT aspectsecurity.com>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XOM-interest Digest, Vol 47, Issue 6
  • Date: Tue, 12 Dec 2006 06:59:34 -0500

Jeff Williams wrote:

I see people using CDATA to send around chunks of stuff that they don't
know how to turn into real XML.

They may not, but I do. So do the crackers. Banning CDATA sections does not address the real problem.

To me that increases the danger that
someone's going to blow it. Either they're going to write their own
mini-parser for the CDATA stuff, or they're going to pass something
dangerous in there. Many Ajax applications are passing around chunks of
javascript inside CDATA (Backbase does this for example). Yikes.

And the *same* application can pass that JavaScript around without using CDATA. Banning CDATA sections does not address the real problem.

CDATA can also be used to obfuscate certain kinds of attacks. E.g.

<![CDATA[<IMG SRC="javas]]><![CDATA[cript:alert('XSS');">]]>

This obfuscates nothing if the security people are savvy enough to use an XML parser. The bug here is not the CDATA section. It is the use of non-XML tools to scan XML data.

It still seems reasonable to me to take a positive security model and
ban CDATA if you are not 100% sure that it is safe. I'm not convinced
yet.

That's ridiculous and bad logic. I am not 100% sure it is safe to get out of bed in the morning, but I do it anyway. real security requires understanding the environment in which you operate and making knowledgeable determinations of risks. Absent further evidence of parser bugs that has yet to be presented, I am cautiously optimistic about CDATA section security.

In fact, I am far more optimistic about the security of an XML based system than I am about the security of a non-XML system. For reasons why see http://www-128.ibm.com/developerworks/java/library/j-fuzztest.html


The fact is, every real application I've seen that uses XML hasn't done
nearly a good enough job of making sure the data is safe before using
it. Perhaps there's a false sense of security that comes from the
strength of the parsers. Or maybe people are using too many wizards. Or
maybe people just think nobody would tamper with XML data. I'm not sure.
But the vulnerabilities are real.

Really. Every one? You must have very high standards. Perhaps my standards aren't as high as yours, but I will say that a large proportion of all real-world applications I see (not just XML-using ones, mind you) do not do a good enough job of verifying input data before accepting it. In my experience the XML using ones do a much better job of verifying input and handling incorrect input.

I also find that when I really do care about maximum security over input data, XML makes it far easier to get this since I don't have to invent my own BNF grammar and parser. Validation also helps. The more I can do declaratively and the less I have to do myself the better. Again, see http://www-128.ibm.com/developerworks/java/library/j-fuzztest.html
for more thoughts on this.

And that's IF the parsers are perfect. People used to think ASN.1
parsers were secure too.

Most of the parsers are open source. In fact, I think all but one of the major parsers are. If you find a real bug, holler, and we'll fix it fast; but there's not a lot we can do about unfounded speculation.

--
Elliotte Rusty Harold elharo AT metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/




Archive powered by MHonArc 2.6.24.

Top of Page