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

Before getting too deep into the weeds, how opposed are you to the
currently specified syntax? :)

Using Google's implementation experience as a basis, Artur, et al. have
been putting together a good deal of ancillary material and tooling to
educate/assist developers with regard to preventing XSS with
`'strict-dynamic'`. It seemed reasonable to do so after the discussions
referenced earlier in the thread, but if Mozilla turns out to be strongly
opposed to the syntax, then they'll probably need to hold off on
publication (and potentially recall already published papers like the one
we're discussing in the other thread) in order to reduce developer
confusion. That would be a shame.

On Fri, Sep 9, 2016 at 9:32 AM, Daniel Veditz <dveditz@mozilla.com> wrote:

> On 9/8/16 1:25 PM, Artur Janc wrote:
> > - 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.
>
> ... which was an ugly but necessary hack in CSP2.


"Ugly but necessary" describes much of CSP, doesn't it? :)


> The directive-level override was built-in from the beginning, with *-src
> directives
> overriding default-src, and later frame-src overriding child-src.
>

This seems to reinforce Artur's central point: CSP has overriding
mechanisms built in from the beginning, and we've historically added new
features (like 'nonce-*') by extending the overrides. It seems reasonable
to call that mechanism "normal" at this point.

> 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 :(
>
> Seems much easier to understand to me: use script policy-A in old
> browsers and script policy-B in new browsers, one or the other, a choice
> of two. with 'strict-dynamic' a keyword you are mentally understanding a
> policy as one thing until you hit that keyword--which could be
> anywhere--and then you have to backtrack to figure out what parts are
> actually ignored.
>

I'm still not terribly clear on your proposal, Dan. Is it something like
the following?

```
    script-src 'unsafe-inline' https: 'nonce-abcdefg'; dynamic-script-src
'nonce-abcdefg'
```

If that strawman is something like what you'd like to see, then I'd naively
claim that an aversion to "backtracking" is equally relevant: "Oh, they're
whitelisting inline script and `https:`. Oh, wait, no. There's a nonce, so
no 'unsafe-inline'. Oh, wait, no. There's this other directive. So they're
dynamically whitelisting nonced sources. Got it."


> > - 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.
>
> Yes, if you used the nonce in the CSP2-level policy you'd have to repeat
> it. I agree it's more verbose but that's not necessarily inelegant.
>

Arguing about "elegance" is unlikely to get us anywhere, as I think it's
clear that CSP's syntax isn't, and isn't going to be. :)

I'd suggest that the verbosity introduces opportunities to screw things up,
in that you'll need to ensure that the nonce is repeated correctly, and you
don't accidentally generate a new one when processing the CSP template.

> 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.
>
> That policy does almost nothing to protect a site in a browser that does
> not honor 'strict-dynamic'.


1. The claim in the paper discussed in the other thread is that many
whitelists are equally lacking in protective power.

2. We're all going to ship `'strict-dynamic'`, right? So this won't be a
problem in a year. :)

> 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.
>
> Yes, that works. Duplicating most of two entire policies seems more
> 'inelegant' to me than duplicating a nonce across two directives, but
> that's the kind of clarity I was going for.
>

Artur can correct me if I'm wrong, but I believe that some Google
properties are doing this today to get both the XSS protection of nonces +
dynamism, and the architectural restrictions of whitelists.

-mike