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

Re: Hashes/Nonce Source and unsafe-inline

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Thu, 12 Dec 2013 18:01:01 -0800
Message-ID: <CAPfop_3zeehb1KUx17ZKhHZHbFaHkpghMpNruW8v_9SCncrBSQ@mail.gmail.com>
To: Dionysis Zindros <dionyziz@gmail.com>
Cc: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Dan Veditz <dveditz@mozilla.com>
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.


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 02:01:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:35 UTC