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

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

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
>
>