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

[Oleg Gryb <oleg_gryb@yahoo.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).   

I'm not sure why you call these changes "unforeseen": it happens all the time and developers should be ready to accommodate the change. I think XSD is more flexible in this case than application code: you'll need to change [0-9]{5} to [0-9]{9}


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

It might be or might not be true. I know cases where validation is required on perimeter and in application, in other cases it can be sufficient to do it on perimeter. As I wrote, I don't believe that doing validation inside application is more reliable than doing the same in XSD. Less flexible - yes, more reliable - no. I agree that there may be cases of complex semantic that can not be expressed by a regular expression, but it doesn't mean that we should not try to enforce simpler rules using more flexible and simpler solutions: declarative (XSD) rather than procedural (coding).

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

I've seen anti-SQL-injection solutions that are based on regular expressions, meaning that it can be done in XSD as well.

>than about strings
> being a few bytes too long.
> 
DoS attacks are usually related to strings that are much, much longer compare with what you've anticipated, that's why I've mentioned that having strings with constarins is more secure than having an abstract strings with no constrains. Please notice that DoS attack will happen before the application will have a chance to validate anything, so in this case application level validation is not even an option.

> > >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 was trying to say that html has been created without real data validation in mind and existing implementation (browsers) made the situation even worse, because every browser is actually a standard itself. It's different in XML world where XSD is used to formally define syntax and XML validting parsers are interoperable to a much bigger degree than browsers.

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

If system's ability to scale depends on the XML validation options then this scalability solution is not worth much. We're talking about horizontal scalability here, right? It doesn't matter if you do validation or not, because sooner or later you'll have to add more computational power behind your load balancers (assuming that your business evolves over time). Probably with validation on it will happen a little bit earlier, but what is the delta that we're talking about here? My estimate is that for a reasonable XML size (few dozens of K) it's in millis, not even in dozens of millis. At least this is what I've seen for some good validting parsers. This time is negligibly small compare with that spent on other tasks during a typical financial transaction.

> 
> > 
> > >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
>  
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> xacml-users-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail:
> xacml-users-help@lists.oasis-open.org