XOM API for Processing XML with Java

["Steve Loughran" <steve.loughran AT gmail.com>]

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 )