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

On 07/21/2013 12:08 PM, Daniel Veditz 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).
> 

While the spec currently allows nonce-source on external scripts, I
think we should limit it to inline scripts (and styles). As you point
out, once we implement the path matching in CSP 1.1, it is unnecessary
to use nonces on external scripts. This merits discussion in another,
dedicated, thread. A decision on this would determine whether it makes
sense to mix nonce and unsafe-inline.

> 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.
> 

Yes, that ickiness is what made me reject the idea at first. On the
other hand, if there is no use case for combining nonce-source and
unsafe-inline, then there is no harm in allowing nonce-source to
override unsafe-inline.

> 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
>

Received on Wednesday, 7 August 2013 05:59:52 UTC