Cart
[Home] [By Thread] [By Date] [Recent Entries]
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
