- From: Neil Matatall <neilm@twitter.com>
- Date: Fri, 13 Dec 2013 11:59:27 -0800
- To: Devdatta Akhawe <dev.akhawe@gmail.com>
- Cc: Dionysis Zindros <dionyziz@gmail.com>, Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Dan Veditz <dveditz@mozilla.com>
Dev, This change was for backwards compatibility reasons. So the 'unsafe-inline' would be bypassed by actions performed by nonce-validated scripts? On Fri, Dec 13, 2013 at 11:26 AM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote: > For example, https://www.facebook.com/ has a policy that includes > 'unsafe-inline' and the page uses inline event handlers. Seemingly, > the aim of the policy is to control what external scripts are loaded > and not just XSS mitigation. > > Imagine a website that wants to do get finer-grained control and uses > nonces for this. So, for example, the policy could include "script-src > 'unsafe-inline' nonce-longrandomvalue" and some trusted code on the > page knows the longrandomvalue and only that code can add external > scripts to the page by creating a script element with longrandomvalue > as the nonce attribute. With the change that Mike pushed, inline event > handlers for this page would stop working. This does not look right to > me. > > --dev > > On 13 December 2013 00:13, Dionysis Zindros <dionyziz@gmail.com> wrote: >> I'm not really sure what you mean by this, could you elaborate, maybe >> with an example? >> >> Thank you. >> >> On Thu, Dec 12, 2013 at 6:01 PM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote: >>> I agree with you on hash sources. I don't believe this is true for >>> nonce sources, since one of the use cases nonces support is including >>> scripts from URLs that you only know at runtime. >>> >>> --dev >>> >>> On 12 December 2013 16:00, Dionysis Zindros <dionyziz@gmail.com> wrote: >>>> On Thu, Dec 12, 2013 at 3:34 PM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote: >>>>> Hi >>>>> >>>>> [creating a separate thread since there were other discussions ongoing >>>>> in the other] >>>>> >>>>>> 2. 'unsafe-inline' is disabled if either a hash or nonce is present. >>>>>> [3] https://dvcs.w3.org/hg/content-security-policy/rev/8db37e53da82 >>>>> >>>>> Imagine a website that wants to control what external scripts are >>>>> loaded. The website uses inline event handlers too. The hosts for >>>>> external scripts can be dynamic (e.g., it is on a CDN) and thus it >>>>> uses nonces to load them at runtime. In the new design, all the event >>>>> handlers would stop working. I am not sure this is what we want. >>>>> >>>> >>>> Inline event handlers are insecure and prone to XSS, so we want to >>>> block them. There's no point in enabling both unsafe-inline and (hash >>>> or nonce) at the same time. The point of a hash or a nonce is to block >>>> all inline scripts except the ones whitelisted. Allowing inline >>>> scripts completely defeats the purpose of having hashes or nonces. >>>> >>>>> >>>>> Thanks >>>>> Dev >>>>> >
Received on Friday, 13 December 2013 19:59:55 UTC