Re: [xml-dev] The <any/> element: bane of security or savior of versioni

["bryan rasmussen" <rasmussen.bryan@gmail.com>]

Of course note that some of these examples are overdrawn worst case
scenarios, but I have certainly seen lesser variations of them in some
companies and large organizations that had to deal with Any and could
not. And that were any's that were reasonably walled off from the rest
of the markup (in an element defined as extensible. )

Cheers,
Bryan Rasmussen

On 10/19/07, bryan rasmussen <rasmussen.bryan@gmail.com> wrote:
> Possible problems with Any:
>
> well many problems with things are problems because we cannot count on
> people to either use them correctly, or use the things that depend on
> them correctly.
>
> Let us suppose we have an any allowed in the the following xml fragment
>
> <a>
>  <b></b>
>  <c></c>
>  <d></d>
> {any allowed here}
> </a>
>
> This fragment is in a format of business critical data, not in
> presentational markup.
> This data is handled via a system with some millions of lines of code
> programmed over several years by dozens of people.
>
> The following bugs have been determined to be in the system:
>
> -----------------------------------------------------------------------------------------------
> If condition X occurs somewhere in the passing of the XML message
> process X is run which recursively goes over the data entering all
> data from elements into a ridiculously bad database structure where
> field names match element names.
>
> When Any occurs in xml documents that are ran through process X the
> system crashes.
>
> Somebody is working on this bug though and they will probably find it soon.
>
> -----------------------------------------------------------------------------------------------
>
> There are a number of stylesheets for various output media. These
> stylesheets have all been written in the push style to increase
> maintainability and with reference to the definition of elements in
> the namespace.
>
> These stylesheets produce incorrect presentations when ran with
> elements that extend the known namespace - i.e. when any is used.
> Nobody has found out about this yet but somebody has noticed that
> there are validation errors coming out in some instances when the
> instances are ran through the format 2 xsl-fo stylesheets because the
> xsl-fo renderer used is rendereX with validation of the XSL-FO.
> Somebody is trying to debug this but it is somewhat difficult because
> the guy who wrote the stylesheets is no longer there, but nobody at
> the company knows XSL-FO.
>
> Also format 2 legacy html stylesheet produces output that crashes
> Netscape 4 when some infrequent user of that browser shows up. That is
> also set to debug, nobody knows what causes it though. The best guess
> is it is somewhere on the server side not in the transformation, and
> nobody is looking at it because hey, its Netscape 4.
>
> -----------------------------------------------------------------------------------------------
>
> There are any number of bits of code throughout this big big system
> where someone gets a and has to read the children of a into an array
> and blah blah blah. In some cases depending on how it was done the
> system fails, in other cases the data gets added into the last item in
> the array blah blah blah. In some bits of legacy data from a long time
> ago before they found out they had these problems somebody made
> extension y that had an integer datatype. d was a decimal datatype. In
> some arrays that were really important for calculating some sort of
> tax d and extension y ended up getting concatenated. Nobody has
> actually realized that there are small decimal inconsistencies in the
> data. This will be figured out in the next accounting cycle.
>
> Finally the IT support and consultants and programmers for this large
> organization do not necessarily talk to each other about the bugs they
> find in different non-connected parts. For example that the XSL-FO
> stylesheets have a bug will not necessarily be communicated to the
> programmers trying to figure out where the bug is on the format 2 html
> presentation server.
>
> The upshot is that: given that people do not build large systems
> invariably after best practices one cannot say well just make sure you
> don't do any of those mistakes then.
>
> One must realize that decisions in the extensibility of the format can
> cause those mistakes.
>
> Any in those contexts can lead to higher chances of things being
> fucked up. Therefore, while I do not agree that Any is too dangerous
> to ever use, Any is definitely to dangerous to just assume there is no
> problem with it.
>
> Cheers,
> Bryan Rasmussen
>
>
>
>
>
>
>
>
> On 10/19/07, David Carlisle <davidc@nag.co.uk> wrote:
> >
> >
> >
> > < From a security perspective the <any/> element represents a high risk
> > > and should be avoided if possible.  In environments where schema
> > > validation is used in a guarding capacity, a schema that uses the
> > > <any/> element is likely to be marked as high risk or even forbidden
> > > from use.
> >
> > That seems a rather bizare characterisation, and compared to otehr
> > features of XSD (for example lax or skip validation) what is teh problem
> > that you see with <any/> ?
> >
> > David
> >
> > ________________________________________________________________________
> > The Numerical Algorithms Group Ltd is a company registered in England
> > and Wales with company number 1249803. The registered office is:
> > Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
> >
> > This e-mail has been scanned for all viruses by Star. The service is
> > powered by MessageLabs.
> > ________________________________________________________________________
> >
> > _______________________________________________________________________
> >
> > XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> > to support XML implementation and development. To minimize
> > spam in the archives, you must subscribe before posting.
> >
> > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> > subscribe: xml-dev-subscribe@lists.xml.org
> > List archive: http://lists.xml.org/archives/xml-dev/
> > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> >
> >
>