RE: The <any/> element: bane of security or savior of versioni
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 . 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  http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/ -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 --------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
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