Re: Hashes/Nonce Source and unsafe-inline

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