W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2013

Re: [webappsec] new draft of UI Security available

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 26 Mar 2013 11:26:06 +0000
Message-ID: <CADnb78hSu6s7YWbd6oAA86xNJ0wDEJEa8Ooy4ohdU_2SOVXjBg@mail.gmail.com>
To: "Hill, Brad" <bhill@paypal-inc.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Mar 25, 2013 at 10:43 PM, Hill, Brad <bhill@paypal-inc.com> wrote:
> I added the UIEvent partial and a ref in the Script Interfaces the base CSP 1.1 interfaces.  I hope that clarifies it somewhat?

It's not really clear from the text at what point unsafe starts
returning true. Also, developer code should probably check both
isTrusted and unsafe. unsafe does not make much sense for synthetic
events as far as I can tell. Also, if developers need to rely on it,
you probably want to add [Unforgeable] to the IDL so it cannot be
faked.


> My question is does it make more sense to define the additional properties as I have done, e.g.:
>
> partial interface SecurityPolicyViolationEvent : Event
>
> or as:
>
> interface UISecurityPolicyViolationEvent: SecurityPolicyViolationEvent

That depends. Is this a new event or is it the same event? If it's the
same event you want to use partial to augment it. Ideally though you
do not split the definition of an event across specifications.


> The only complexity would be, I think, for servers processing such reports to take this XPath and compare it against the source text to identify the target.  Certainly that is optional - report recipients are free to ignore any fields they wish.

How can you even be sure that works given the myriad of DOM
manipulations that happen in an application today?


>> In general this specification lacks a model. There's a bunch of features and
>> descriptions of them, but it is not exactly clear where they matter in an
>> implementation.
>
> Can you provide a little more constructive assistance here?  The assumption is that these are additional directives in the context of an existing implementation of CSP, so much of the processing model is assumed to apply from that.  Is that the issue, or something else?

Well the specification is not written coherently as far as I can tell.
Reading http://ln.hixie.ch/?start=1140242962&count=1 might help. E.g.
the inputProtection property is defined as "A boolean representing the
logical or of whether the input-protection directive is present or
implied in each of the active CSP policies." which is not a
conformance statement at all. Also, it seems like that interface
should be SecurityPolicy, not just Security.

Looking for must statements through the specification there's only a
couple, while it seems like there are more requirements made. By
describing things in a grammar only, error handling seems somewhat
wonky. E.g. does the parsing of a CSP policy really depend on the
evolution of the Selectors grammar? What is missing is a clear
unambiguous processing model.


-- 
http://annevankesteren.nl/
Received on Tuesday, 26 March 2013 11:26:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:01 UTC