OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



> From: Cahill, Conor P <conor.p.cahill@intel.com>
> Subject: RE: [xacml-users] Validating XACML policies and requests against XSD
> To: "oleg@gryb.info" <oleg@gryb.info>, "xacml-users@lists.oasis-open.org" <xacml-users@lists.oasis-open.org>, "xacml-comments@lists.oasis-open.org" <xacml-comments@lists.oasis-open.org>
> Date: Tuesday, January 13, 2009, 5:27 PM

> There's a whole world of difference between schema
> validation (which is data structure validation) and data
> validation.   
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. You can even use regular expression or enumerations to determine what the valid values are.  The first approach (abstract types) is considered as insecure, the second one allows moving data validation from an application to an XML validating parser. I would trust a standard XML validating parser more than any custom code, because the former was written by professionals and reviewed by many eyes. XACML schema uses abstract data types in many cases (and this is an area for improvements), but it has enumerations as well (e.g. for PDP's decisions). Using very big strings or very 'deep' XML elements can be used as an effective DoS attack against an XML parser if max length or max depth is not enforced by XSD.


>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 may be some weaknesses from a lack of schema
> validation (I'm not convinced one way or the other yet),
> but as far as I know, the vast, vast majority of real-world
> XML interfaces out there do *not* perform explicit schema
> validation (they perform a level of implicit schema
> validation by processing elements that they know and
> understand and frequently ignore elements that they
> don't know/understand (unless those elements were in
> SOAP headers and flagged with mustUnderstand)). 
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.

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

Oleg.
> 
> Conor
> 
> > -----Original Message-----
> > From: Oleg Gryb [mailto:oleg_gryb@yahoo.com]
> > Sent: Tuesday, January 13, 2009 12:40 PM
> > To: xacml-users@lists.oasis-open.org;
> xacml-comments@lists.oasis-
> > open.org
> > Subject: [xacml-users] Validating XACML policies and
> requests against
> > XSD
> > 
> > I've noticed lately that some commercial and open
> source PDP engines do
> > not validate requests and policies against XSD that is
> a part of XACML
> > specification. I could see two problems related to
> that:
> > 
> > 1. Each and every security auditor would say that
> absence of input data
> > validation is a security breach in waiting. It's
> true even for
> > 'regular' business applications. In the case
> of authorization systems
> > this fact should be given even a bigger attention
> considering
> > criticality of these systems.
> > 
> > 2. It affects PDP's interoperability. Example that
> Hao has provided
> > makes me thing that sunxacml disregards namespaces, it
> means that it
> > won't be interoperable with any PDP engine that
> does the validation
> > against XSD. Seth, please let me know if my
> observation is not correct.
> > 
> > I think it should be clearly stated in the XACML
> specification that if
> > a request or policy is not compliant with XSDs the
> process of
> > evaluation should not even start and all invalid
> requests and policies
> > should be rejected by PDP.
> > 
> > 
> > 
> > 
> > 
> > 
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> xacml-users-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail:
> xacml-users-help@lists.oasis-open.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> xacml-users-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail:
> xacml-users-help@lists.oasis-open.org


      


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]