[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: The <any/> element: bane of security or savior of versioni

• From: noah_mendelsohn@u...
• To: "Michael Kay" <mike@s...>
• Date: Fri, 19 Oct 2007 13:43:55 -0400

We talked about issues relating to this on and off for several years while 
working on Schema 1.1.  I think that asking "Is <xsd:any> too much of a 
security risk or do we need it for versioning?" doesn't give quite enough 
context.  There are ways to use xsd:any that cause major security 
problems, IMO, and ways that don't.  The first thing to ask yourself is: 
what is your application relying on schema validation to do?  There is no 
one right answer to this, but almost surely you're relying on it to weed 
out a certain class of input that you don't want to deal with.

Now, let's go a bit deeper.  What's your API into the schema validation? 
If you're just getting back a simple valid/not-valid bit, and if you're 
assuming that your schema enforces (let's say) all the needed element 
occurrence constraints for your application, then that <xsd:any> is likely 
to allow in a lot.  You can indeed easily conjure up cases where 
significant security issues would result.

Now let's make a different assumption about how those same wildcards might 
be used.  XSD has the famous (infamous) UPA rule, which means that a 
validator can determine not only which content is valid, but which content 
was accepted by a particular wildcard, and which content was accepted by 
something else like an element reference.  Let's assume this time that 
your API can tell the application:  "this element was accepted by an 
explicit element declaration, but that element was accepted by that 
wildcard over there."  Now your application has some very useful 
information for closing that security loophole:  it can assume that 
anything accepted by element declarations is really what you're expecting, 
and things accepted by that <xsd:any> are some sort of extension content 
and should be treated as such.  Perhaps you say:  "Well, future proofing 
isn't the only reason I use xsd:any".  Fine.  Put an <xsd:appinfo> on each 
wildcard to indicate what it's being used for, and make sure the API your 
processor exposes let's you get at that.   Now you know that even some of 
the content accepted by <xsd:any> was truly expected (think about the 
contents of a SOAP envelope body), but that other content accepted by 
different wildcards was not.

Do all current Schema APIs make this easy or even possible?  Presumably 
not, but that's arguably a requirement that future versions of the APIs 
will have to address, and not necessarily a flaw in XSD or in the use of 
wildcards for versioning.

More fundamentally, we made an interesting discovery while discussing 
language versioning.  Our users seemed to fall into at least two main 
groups:

1) Users who want even extended versions of their languages to be 
validated by older schemas, but with some indication as to which content 
was truly expected and which just tolerated as a probable extension.  The 
xsd:any approach is most likely to appeal to such users.

2) User who's view is:  if I write a V1 schema then I want it to accept 
only those things I really know about in V1.  That means it's fragile, in 
the sense that just one little extension will cause my documents to be 
invalid.  What I really want the schema processor to do is to run in two 
modes.  The first, the traditional mode would tell me:  "that document's 
not valid".  The second one should say:  "but if you'd only made these 
little bitty changes to your document (e.g. leaving out that element over 
there), it would have been valid."

For XSD 1.1 we mostly emphasized approach #1, though I think there are 
some things in the handling of fallback from an unresolved xsi:type that 
crept in and that feel a bit like perspective #2.  Anyway, I don't think 
either approach is "right".   It took us awhile to realize that different 
users prefer different things.  Then we had to decide how much new 
mechanism to build, and you can see the results of our decisions in the 
draft at [1].

I strongly feel that there is no security issue using <xsd:any> for 
extensibility, as long as you have the right APIs to help your application 
use validation as intended.  Hope this helps.

Noah

[1] http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

• References:
  • RE: The <any/> element: bane of security or savior of versioning?
    • From: "Michael Kay" <mike@s...>