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

Responses inline.

On Sun, Jul 21, 2013 at 12:08 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-.
>
> Agreed about this potentially causing confusion. Could this be alleviated
by adding to the current usage notes on script-src about interaction with
'unsafe-inline' and valid nonces?

I'm not married to the dual meaning of 'unsafe-inline' or to the
'ignore-unsafe-inline' approach, but I would strongly like provide a single
backward compatible CSP. The reason I suggested the former, is that there
was verbiage that mentioned this behavior (as part of the script-nonce
directive that has now been removed).

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.
>
> Until we are confident that we won't break older browser versions (which
only support CSP 1.0), we can't transition to an enforcing CSP 1.1 policy.
This is why I brought this up as a way to speed up CSP 1.1 deployment in
enforcing mode without worrying about breaking functionality on older CSP
1.0 browsers.


> >  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.
>
> +1. If we have to go the UA specific CSP enforcing route, we will, but it
will likely lead to be a slower rollout---likely have to support a
whitelist of UAs which can receive CSP 1.1, before switching to a list of
UAs which receive CSP 1.0.

Thanks,
Danesh