XOM API for Processing XML with Java

[Tatu Saloranta <cowtowncoder AT yahoo.com>]

--- Jeff Williams <jeff.williams AT aspectsecurity.com>
wrote:

> Elliotte Harold wrote:
> 
> > Either you let in XML or you don't. If you do let
> it in the robust 
> > nature of well-formedness and optional validity
> checking, means XML 
> > solutions are more secure. I'm much more confident
> with an XML system 
> > than I am with anything hand-rolled, including
> fake XML parsers. 
> 
...
> So what if the parser is better? The point is that

I assume Elliotte meant that sub-standard parsers
might
have flaws that could perhaps be abused, more so than
parsers that literally interpret xml specification
regarding handling of xml content. Although Java is
not quite as fragile as some of compiled languages
(regarding buffer overflows and such), hand-rolled
parsers (serializers, processors) are more prone to
having unintended features than more established
parsers.

There are individual aspects of xml processing (such
as automatic expansion of external entities defined
in DTD subsets, which can balloon document sizes
beyond
boundary), but besides these features (that are
well-known)
it is quite straightforward to evaluate all potential
threats
that low-level xml processing itself can have. That
list
is rather short. It can not contain nifty ActiveX
controls,
or VB macros that would be automatically evaluated.
For getting such holes, you need to employ actual
idiot coders.

> it's easy to send
> around attacks inside XML that's well-formed and
> validated. If a

XML contents are just data. What one makes of it
depends on end-points. And that has little to
do with XML, and practically nothing to do with
distinction between CDATA and character segments.
I assume we are still discussing the original
question here.

> security person is concerned about what's actually
> inside, good. They
> need to make sure the data is safe enough to use. Is
> it going to a

And once again, what relevance does this have with
CDATA sections?

> database? Control business logic? Store in a file?
> Render in browser?
> Some other interpreter?
> 
> So don't add a feature to XOM - I don't care. But
> just because you've
> received "valid" XML doesn't mean you should trust
> it.

It seems to me that you reading much more into data
than most people are.

The main problem in this particular case (not allowing
CDATA sections, only regular character content) 
does indeed appear to be security group's lack of
knowledge regarding xml. How can they effectively be
responsible for securing things they don't have a clue
about?

But after all is said and done, I do agree that the
pragmatic short-term solution is to get rid of the
dang CDATA sections. ;-)
This because with most companies, the security group
does
have the final say on what goes through the firewalls
and what doesn't. Whether they have a clue or not.

-+ Tatu +-




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com