Re: CSP 1.1: Nonce-source and unsafe-inline

> When I say "prefer" I don't mean I like either suggestion enough to want
to implement it. Willing to keep talking about it though.

+1 this is important to twitter.
On Jul 21, 2013 12:09 PM, "Daniel Veditz" <dveditz@mozilla.com> wrote:

> On 7/19/2013 1:48 PM, Garrett Robinson wrote:
> > On 07/17/2013 03:12 PM, Danesh Irani wrote:
> >> From a web app deployment perspective it would be great if having
> >> a valid nonce-source invalidated an 'unsafe-inline', as this would
> >> allow having a single CSP 1.1 header which provides addition
> >> security for new browsers, but also works for old browsers (sort of
> >> like providing a backward-compatible policy and avoiding the
> >> unpleasantness of user-agent specific CSP).
> >
> > Having the same policy do two different things depending on the
> > user's browser is confusing.
>
> At the extreme the same policy does two very different things depending
> on whether the user's browser supports CSP at all; it's not the
> strongest argument.
>
> Does it otherwise make any sense to mix nonce and unsafe-inline in a
> single policy? I guess it might: you could allow inline scripts, scripts
> from explicitly whitelisted domains, and then scripts with src= from an
> unlisted domain but with a nonce. Unlike individual inline scripts,
> however, that use of nonce isn't enabling anything you couldn't already
> do by whitelisting a full path to a specific file (it might be more
> compact though).
>
> We wouldn't lose any capabilities by adopting Danesh's suggestion, and
> it could enable a more graceful transition between "CSP-1.0" user agents
> and "CSP-1.1" UAs. It does feel kind of icky to have a keyword that
> means something in some contexts but is ignored in others. For clarity
> I'd prefer instead adding an explicit 'ignore-unsafe-inline' keyword
> which would be ignored by CSP 1.0 clients as unknown and in CSP 1.1
> clients the relationship between the two keywords is clear, unlike nonce-.
>
> When I say "prefer" I don't mean I like either suggestion enough to want
> to implement it. Willing to keep talking about it though.
>
> In the longer run CSP 1.0 clients should disappear relatively quickly:
> both Chrome and Firefox have pretty good uptake rates for new versions.
> We could just ignore the issue and assume sites won't use script nonce
> until there's reasonable uptake in adoption. Those sites could help us
> browser makers by haranguing broken users into upgrading.
>
>   <script nonce="53kr37">var nonce="enabled";</script>
>
>   // later non-inline script
>   if (!nonce)
>     alert("Your outdated browser won't work here--please update!");
>
> >  Couldn't you achieve the same result (deploying the best possibly
> > policy, depending on browser) easily by choosing the policy to send
> > based on the User Agent string, or by using the experimental meta
> > element support in 1.1?
>
> Not easily. UA sniffing is fraught with problems, and <meta> CSP
> policies currently don't support the important reporting feature.
> Possible though.
>
> -Dan Veditz
>
>