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: "Steve Loughran" <steve.loughran AT gmail.com>
  • To: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] XOM-interest Digest, Vol 47, Issue 6
  • Date: Tue, 12 Dec 2006 09:31:29 +0000

On 12/12/06, Jeff Williams <jeff.williams AT aspectsecurity.com> wrote:
> 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.


Which is precisely why the Axis security guidelines tell you not to do that
http://ws.apache.org/axis/java/security.html#ParameterAttacks


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?



If it doesnt. then its something we should fix. There's no reason to
stop Xom being secure as well as usable. Indeed, I'd argue that the
more complex tools (DOM) are less secure because they are less usabel.

as an aside, I assume you disable entity processing in the parser? Rome
forgot:
https://rome.dev.java.net/issues/show_bug.cgi?id=46

> 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.

I could pass that same script around with escapes. Wait a minute. I
do. But the stuff I pass around gets executed in a secure sandbox and
I only accept connections from trusted callers.

I dont think CDATA is the weak point in XML security. Not 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.

I'd argue that O/X mapping, the turning of untrusted data into object
data that people assume is 'safe' is a major risk. SOAP stacks do this
more than anything else.

That is, its not so much the wire format as what things do with it at
the far end. I'm too busy seeing SQL injection attacks in the wild to
care about Xpath attacks, which at least indicate someone is staying
in the XML space.


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

If I were to put a back door in any apache code, xerces is where I'd
do it. One little PI and I'd own most SOAP and REST endpoints on the
planet. The code is complex enough nobody would notice for a while.

-Steve

(Author of the Axis security guidelines
http://ws.apache.org/axis/java/security.html )




Archive powered by MHonArc 2.6.24.

Top of Page