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

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

From: Danesh Irani <danesh@google.com>
Date: Tue, 23 Jul 2013 10:10:34 -0700
Message-ID: <CAPDPM2bXPc46XFeFOTjWGFxWOTyskNRoqrW507Y9My8b75YraA@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
Cc: Garrett Robinson <grobinson@mozilla.com>, public-webappsec@w3.org
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.

Received on Tuesday, 23 July 2013 17:11:23 UTC

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