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

Re: Hashes/Nonce Source and unsafe-inline

From: Pete Freitag <pete@foundeo.com>
Date: Fri, 13 Dec 2013 15:53:13 -0500
Message-ID: <CAADZ8V7MPt3i1ZpQPmHVqtXDJC6kbGR_5DADW6MbS_v1LbDLew@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>
On Fri, Dec 13, 2013 at 2:26 PM, Devdatta Akhawe <dev.akhawe@gmail.com>wrote:

> 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, to elaborate on what Neil mentioned... My understanding is that when
you specify both unsafe-inline and a nonce (or a hash) in CSP 1.1,
unsafe-inline is ignored. this allows a user agent that only supports CSP
1.0 to continue to execute the scripts (ref:
https://dvcs.w3.org/hg/content-security-policy/rev/8db37e53da82). The huge
advantage to this approach is that developers don't need to specify
different Content-Security-Policy headers to clients that only support CSP
1.0 to be able to use the nonce or hash.

Are you suggesting that the behavior should be to allow inline event
handlers, and only allow script tags with a valid nonce to execute when
both unsafe-inline and a nonce are present? I prefer the backwards
compatible route.



--
Pete Freitag
http://foundeo.com/
http://content-security-policy.com/ - CSP Quick Reference
Received on Friday, 13 December 2013 20:54:02 UTC

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