XOM API for Processing XML with Java

["Jeff Williams" <jeff.williams AT aspectsecurity.com>]

> I don't think you understand what's going on here.

I'll have to try to be more clear.

Even if the parser is perfect, you can trick applications into including
attacks in XML documents. Anyone including user data in their XML
anywhere?

Even if the parser is perfect, these attacks can subvert the
applications that use the XML. For example, you can send a SQL injection
attack inside an XML element to a web service that is backed by a
database. I've found this flaw in several commercial products.

Even if the parser is perfect, XSS attacks inside XML or XML fragments
can compromise the browser's security. Virtually every "Web 2.0"
application has this flaw, whether they use REST or SOAP, JSON or XML --
because a lot of it ends up in the browser eventually.

> If a security person wants to look inside the file, they need to use
an XML parser.

Agreed.  And they get some assurance that the parsing worked.  But they
get no assurance that the data inside the document is safe to use.

> It's real, though I've never seen it come up in practice, unlike SQL 
> injection which happens all the time.

Have you looked?  XPath code that takes user input is just as likely to
be vulnerable to injection as SQL code that takes user input. I found it
in a customer's application just last week. Thanks to Wolfgang for the
parameterized way to invoke XPath, I hadn't seen that before.  Does it
guarantee injection is impossible in the way that PreparedStatement does
for SQL?

> The security you achieve by banning CDATA sections is just as
effective 
> as the security you get by forbidding people from entering an airport 
> concourse with one 12 oz. bottle of toothpaste but allowing them to 
> enter it with four 3 oz. bottles of toothpaste.

I sort of see this. But I also think CDATA encourages developers to do
dangerous things.

I see people using CDATA to send around chunks of stuff that they don't
know how to turn into real XML.  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.

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

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

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.

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.

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

--Jeff