RE: [xacml-users] Validating XACML policies and requests against XSD

["Cahill, Conor P" <conor.p.cahill@intel.com>]

> It depends on how you define an XML schema. You can use abstract types,
> like a string or an integer or you can add additional constrains to
> your XML types like string that is not longer than and not shorter than
> something. 

Most of the time when these kinds of restraints are put into schema or even hard coded into applications, it leads to unforeseen problems in the future (like hard coding zip codes to 5 digits means that 9 digit zip codes can't be entered).   

That said, any reasonable developer will always put data constraint checks within their application, even if those constraints are listed in the schema.  You can't depend upon the schema validation taking place, less alone that it got it right -- always check that the length you are copying into your destination string is no longer than the space you allocated to that string.

Also, the majority of the problems that take place when there's no input validation is more typically around semantic changes to the code (injecting weird input that causes problems such as SQL injection) than about strings being a few bytes too long.

> >Those same security guys who push hard for web
> > page input data validation don't push for html schema
> > validation because a) most/many web pages would fail such
> > validation and b) the important validation is the data that
> > you are processing.
> I'm not sure what "html schema" means, but I think by design if an HTML
> tag is not understood by a browser it will be skipped. In XML world XSD
> defines a subset of well formed XML documents, in HTML world "well
> formed" is not even a requirement and I think that this is an HTML
> disadvantage if compare with XML.

There is a schema for HTML.  If you had a validating schema the browser would not be able to skip the tag since the page would not be seen by the browser since the schema validation step would have rejected the page.  You make the exact point I am making re: validation.  

> I think that it's all subjective and depends on what business area you
> worked in. The corporate requirements for data validation in financial
> and Healthcare systems that I worked with were very tough and they did
> require validating XML against XSD if the latter is available, so I can
> say that the vast majority of the systems that I worked with did
> require the validation.

They did this for *every* message at runtime? (I'm not talking about development time testing).  Certainly no scalable system could do this reasonably well for large transaction rates.

> 
> >I would also
> > say that the vast majority of weaknesses are due to data
> > content (as opposed to data structure).
> See my notes above: XSD can be just as much related to data field
> content validation as to XML document structure.

I just think that a) content validation does *not* belong in a long lived standard and b) has to be done by the application anyway just to make sure it isn't being fed garbage by someone who snuck something by the schema validation (or to be prepared should the schema validation have to be turned off due to performance reasons) and c) can more easily be done by the application which should have semantic understanding of the data as well (and this puts all of the data validation in one place rather than sticking it in several places in the stack).

Conor