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

Friendly ping. :)

-mike

On Fri, Sep 9, 2016 at 11:29 AM, Mike West <mkwst@google.com> wrote:

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