- From: Dionysis Zindros <dionyziz@gmail.com>
- Date: Fri, 13 Dec 2013 00:13:14 -0800
- To: Devdatta Akhawe <dev.akhawe@gmail.com>
- Cc: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Dan Veditz <dveditz@mozilla.com>
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 08:14:01 UTC