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

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