Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Managing Innovation
 I agree with all of that. I will also adjust my terminology. Old habits like old code change only with concerted effort. :-) The points made about the XML specification needing changes are quite useful. Hopefully, the Core XML WG is paying attention. We've gotten away with it but we know it has to change. What would you say is the best way to get started on that? One might be to get Roger Costello to add a section to his best practices page. It doesn't fix the code but it will increase awareness. len From: David Megginson [mailto:dmeggin@a...] Bullard, Claude L (Len) writes: > Any system can be hacked and security bugs show up in all of them. > The issue of the monoculture is real enough, but not a catastrophe. > One could make the claim that securing one system is all that is > needed, but the facts say otherwise. As John mentioned, you need to be careful about using the word "hacked", because it has different meanings for different people. For many developers, "easily hacked" means "easily extended and maintained". If you use the term "cracked" in your postings, there's no ambiguity. Microsoft is going through a painful, decade-long transition from standalone and single-user to networked and multi-user -- the transition means abandoning many principles that were originally dear to them (and brought them great success in the standalone days), like *always* favouring convenience over security. Some of the optimizations they made, like putting so much in the kernel (including a lot of GUI code), will also keep coming back and biting them for a while, since every bit of code inside the kernel is a potential vulnerability. Posix operating systems also have vulnerabilities, of course, but because they were designed to be multiuser and networked from the start, their fundamental design is more sound: as I mentioned earlier, Posix systems tend to have relatively thin kernels and do most of their work in user space, so they can be hardened to a large extent simply by making sure that the user-space programs do not have root permissions. Not everyone does that, but at least it *can* be done. So, what about XML and its related specifications? I'm afraid that we're more like Microsoft than like the Posix systems: we're starting with glaring security holes like external DTD subsets and external entity references for the sake of convenience, and we will have to fix those holes later if XML ever becomes popular on the Web. With no fixed limit on element names, number of attributes, nesting depth, etc., XML applications can also easily fall prey to buffer-overflow attacks or denial-of-service attacks if they are not very carefully written. I believe that the old SGML declarations were very annoying, but it might not hurt to set some arbitrary, very high limits for the next version of XML, such as Maximum name length: 4096 characters Maximum attributes: 1024 Maximum element nesting depth: 65536 etc. Every robust XML application has to do that anyway to avoid either buffer-overlow or DOS attacks (by memory exhaustion), so it would be a good idea to start spreading a good, standard practice now. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
