Re: [xml-dev] Features of XML Languages that Increase Complexity?

["Simon St.Laurent" <simonstl@simonstl.com>]

On 4/14/13 2:28 PM, David Lee wrote:
> Yes I read those. And those are normal things one might put in a data
> structure reguardless of the markup format.

Yes, but they are completely normal features of XML document processing.
CSV, to use your example, offers none of these things except open content.

> So I am curious why the statement that one shouldn't use XML ...
> that is what makes it *more insecure* then other formats ? Lets
> ignore things like embedded JavaScript ...

I think Roger's approach to deciding what is secure and insecure is
brutally flawed.  However, if you accept his point that those things are
security risks, you absolutely should avoid tools in which they are
common, ordinary, and accepted.

> What *specifically* about XML makes it less secure *intrinsically* ?
> Even simple formats like CSV can suffer from DOS attacks (say sending
> a infinitely long line of text without a field separator ?)

That's about the only thing you can do in CSV, unless you know more
about the interpretation of the content later in the pipeline than "CSV"
itself tells you.

All of the features Roger describes are commonly available in XML tool
chains.  They can be locked out with minimalist processing approaches or
to some extent with the parser generator approach Roger asked about
earlier.  There is no question, however, that you can make a generic XML
processor do a lot more work and consume more resources through abuse of
these features than you can by feeding CSV a never-ending file.

These features all require more tracking than just splitting up a flow
of bytes.  They require their own memory, their own processing, their
own data structures in addition to the flow of the document.

> None of the things Rodger mentioned , in my mind, make XML
> *inherently less secure* then any other data representation modeling
>  the same data.  What about the *format* makes it more prone to
> attacks ?
>
> Say Recursion (one of the listed items)... If recursion was not
> allowed, but yet someone sent a recusive document ... it would be up
>  to the *processor* not the format,, to protect against infinate
> recursion (same as its up to the *CSV processor* to prevent a buffer
>  overflow).

Roger will have to speak for himself, but the "surface area" language
he's using isn't generally about assuming best practices on the part of
the programmer.  It's about assuming that programmers will make
mistakes, and that handing them less complicated things to process will
result in fewer mistakes.

All of the things he lists require careful thought about processor
design.  Even in the best case they will at least slow things down a
bit.  In the worst case they may let attackers bog down massive
quantities of processing resources that aren't necessarily available at
any given moment.  Run a processor into a low memory situation, and
things become much more interesting.

In CSV, you do have to watch for an endless file.  There isn't much else 
to watch for, however.

Thanks,
-- 
Simon St.Laurent
http://simonstl.com/