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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: Re: [ubl-dev] Hybrid approach to local vs. global


> The problem can also be alleviated easily enough by implementors checking the
> namespace and document element of incoming messages, which is basically what
> I always do before considering anything like validation, transformation,
> anything.

Absolutely. All bets are off if the namespace binding are incorrect.
But this would be the same for any validating parser wouln't it.

That is, AFAIK most validating parsers use a schema cache of some
description and compare the namespace bindings in the XML instance to
those in the cache. Obviously if none match, then validation passes
(or perhaps more precisely, is not actually performed - either a false
positive or you deliberately want to ignore).

Fraser.

On 01/03/07, Bryan  Rasmussen <BRS@itst.dk> wrote:
>
> >(2) the problem with global elements during validation -
> >      introduction of additional unexpected "valid" data elements
> >      because of imports and inclusion of other UBL sub-modules.
> >      This, therefore, poses a potential security issue there as well.
>
> hmm. not sure if I agree with that (or at least if I agree 100%).
>
> The problem alluded to in your document is one of the more annoying parts of
> the use of XML schemas, because not very many people are even aware it
> exists. Some day some enterprising cracker is going to figure out a way to
> take advantage of this situation.
>
> The problem is however not present everywhere that global elements are used,
> it is present where global elements are used dependent on the processor used
> and dependent on how validation is set (strict, lax, or skip), for example
> IIRC validating a cac:PaymentMeans with the Invoice Schema on XSV should
> produce a report of valid using lax validation.
>
> I'm not exactly sure what a cbc:ID would produce, probably also valid.
>
> also a <doc:whatever>with a cac:PaymentMeans inside of it would also produce
> valid (at one time, haven't used XSV in a long time and new versions have
> been released so this may be a case of something in an earlier version having
> been changed [not fixed but just changed, from my reading of the Schema
> spec])
>
> But doing any of these things with MSXML's Schema Cache or .Net should
> produce a report of not valid using strict validation.
>
> XMLSpy seems to vary on how it handles the matter.
>
>
> The problem can also be alleviated easily enough by implementors checking the
> namespace and document element of incoming messages, which is basically what
> I always do before considering anything like validation, transformation,
> anything.
>
> Cheers,
> Bryan Rasmussen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>


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