Re: 'strict-dynamic' syntax (was Re: On the Insecurity of Whitelists and the Future of CSP)

Hi Dan,

On Thu, Sep 8, 2016 at 6:15 PM, Mike West <mkwst@google.com> wrote:

> Hey Dan, I'll fork this thread for clarity.
>
> On Thu, Sep 8, 2016 at 5:50 PM, Daniel Veditz <dveditz@mozilla.com> wrote:
>
>> On 9/8/16 6:10 AM, Mike West wrote:
>> > What syntax issue do we need to discuss? If there are remaining syntax
>> > questions, we should resolve them quickly, as Chrome is shipping what's
>> > currently in the spec, and Google sites are beginning to rely on the
>> > currently specified behavior. :)
>>
>> I'm uncomfortable with the multilayered "ignore this if that" within a
>> single directive; it will be especially confusing to developers to have
>> an ignored whitelist of sites. It would be clearer, and more flexible in
>> the future if we need to add options or restrictions on
>> 'strict-dynamic', to have a separate directive which overrides
>> 'script-src' in UAs that understand it (as script-src itself overrides
>> default-src).
>>
>> Because we may want other dynamic types in the future, and to help
>> indicate what it's overriding, we would want to rename it to
>> 'dynamic-script' or something.
>>
>
> My recollection is that we went back and forth on this a bit at the F2F (
> https://www.w3.org/2011/webappsec/minutes/2016-05-17-webapp
> sec-minutes.html), the list (https://lists.w3.org/Archives
> /Public/public-webappsec/2016Jun/0007.html), and agreed upon the current
> syntax. Dev expressed some reservations about the syntax, but ended up
> agreeing with Artur on the current framing (renaming from 'unsafe-dynamic'
> to 'strict-dynamic'). Brad also expressed some reservations early on in the
> thread, but didn't object to the final framing. Mozilla didn't really
> participate in that conversation. I'm a little surprised that you're
> expressing worries about the syntax now. :)
>
> That said, Google is probably the only high-volume consumer of the syntax
> right now. We probably have a (narrowing) window for change.
>
> Would you mind putting together a more concrete proposal that we can talk
> about at TPAC? What flexibility and future types would you like to
> guarantee?
>

It's great to see that you're putting some thought into this! A syntax
change would be fairly painful for us, but I think it's fair game if this
lets us make progress and helps make this adopted more broadly (e.g. in
Firefox).

That said, we briefly considered an approach based on a separate directive
and there were several issues that made it less compelling:

- There is already an "ignore" mechanism in CSP, which works within a
single directive, namely the presence of 'nonce-*' or 'sha*' ignores
'unsafe-inline' for backwards-compatibility. It would be consistent if the
mechanism that replaces the site whitelist behaved similarly (and note that
it's not *multi*layered with 'strict-dynamic' it's just: nonce/hash => drop
'unsafe-inline'; 'strict-dynamic' => drop whitelist)

- With a separate directive there is still the same "ignore this if that"
behavior, but now it's non-local -- you can no longer understand what
scripts are permitted just by looking at script-src. This means that you
need to pay attention to different directives deciding the same behavior,
understand which wins out in which browser, etc. I'd argue it's just as
confusing, if not more :(

- A new directive likely wouldn't be able to completely ignore script-src,
because it would need the nonce defined therein. Or otherwise we would
force the developer to include the nonce in both places (script-src
'nonce-foo123' [something]; new-script-src 'nonce-foo123';) for
backwards-compatibility, which seems fairly inelegant.

- I believe that so far we've had a one-to-one mapping between directives
and resources (with this exception of default-src), but this would change
in this model. Perhaps this is okay, but it also is a bit of a departure
from the status quo.

You've likely considered some of this already, or I might be
misunderstanding parts of the proposal. But, to echo Mike, it would be
great to see this fleshed out in some detail and have the proposal touch
upon some of the above points.

Also, in practice it's probably not *that* likely that developers would be
confused by the whitelist-dropping aspect of 'strict-dynamic'. For one,
many applications can avoid the whitelist altogether to get around the
adoption/maintenance difficulties, and serve a policy such as "script-src
'nonce-foo' 'strict-dynamic' 'unsafe-inline' https:" where the last two
entries will be ignored. Second, if the developer wants to maintain a
whitelist for older browsers, it's easy to split this into two separate CSP
policies, where the original one will be unchanged, and the new CSP header
will only focus on nonce enforcement (same policy as above). We have some
experience that suggests that even developers unfamiliar with CSP can grok
this.

There will certainly be some complexity in the spec and implementations,
but this will be the case regardless of which approach we choose.

Cheers,
-Artur