XOM API for Processing XML with Java

[Elliotte Harold <elharo AT metalab.unc.edu>]

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/