OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Managing Innovation

[ Lists Home | Date Index | Thread Index ]

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.


From: David Megginson [mailto:dmeggin@attglobal.net]

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

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.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS