Re: XSS mitigation in browsers

On 21/01/11 21:47, Devdatta Akhawe wrote:
> IMO, CSP's solution of only making the policy more restrictive is a
> better solution than saying 'first must take precedence'.

However, it only works (or rather, what happens is only obvious) if each 
area of policy has an unambiguous progression from "less restrictive" to 
"more restrictive".

One example of a control which does not obviously do this (I am not 
proposing this idea any more, although it was in an earlier draft of 
something I wrote) is one which restricts where you can include scripts 
in the page:

script-include-only: all | head | body | none

Clearly, all is less restrictive than head or body, and head and body 
are less restrictive than none. But how do you order "head" and "body"?

This is just an example. My meta-point: picking this method of conflict 
resolution may either a) restrict the available sets of policy values 
for more complex directives or b) lead to some surprising results for users.

> It seems to be that this is exactly a good motivation for this. This
> makes this proposal simpler and cleaner, and if the developer wants to
> be notified on SMS in addition to a log to his site, he can do that
> too. Or he can change his last.fm to play songs of doom. But the point
> is the developer should have a programmatic choice of doing what he
> wants -- over the current CSP proposal. The CSP proposal currently
> gets unnecessary cruft like 'should we add the cookies? Whats should
> be the format of the report document? Should we send it if report-uri
> is cross origin? What if there are multiple report-uris?' All these
> look unnecessary to me.

If the CSP policy disables all script, how will the script run which 
detects the event of a policy violation and reports it?

Gerv

Received on Saturday, 22 January 2011 08:40:33 UTC