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

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

From: Neil Matatall <neilm@twitter.com>
Date: Tue, 23 Jul 2013 10:37:14 -0700
Message-ID: <CAOFLtbhcv86c=gg9JZu_M1oEn-2OPjCCHJ38GxCfaVZjhe0wJw@mail.gmail.com>
To: Danesh Irani <danesh@google.com>
Cc: Daniel Veditz <dveditz@mozilla.com>, Garrett Robinson <grobinson@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Nicholas Green <ngreen@twitter.com>
Nick and I were discussing this while writing up the script-hash spec
text. The two should probably behave the same way in regards to
version boundaries. The terse (draft) text is:

> The script-src directive will accept hash-sources as source-expressions. Regardless of whether or not unsafe-line is present, if any hash-sources are present in the source-list of the script-src directive inline scripts MUST not be executed unless any hash-source or nonce-source expression matches the inline script block.

On Tue, Jul 23, 2013 at 10:10 AM, Danesh Irani <danesh@google.com> wrote:
> 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
Received on Tuesday, 23 July 2013 17:37:42 UTC

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