W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2016

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

From: Mike West <mkwst@google.com>
Date: Tue, 13 Sep 2016 21:27:22 +0200
Message-ID: <CAKXHy=eLiW-J--GGRXqp9mtp00MJX2WkurNTwsC+rWq40sgmJQ@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
Cc: Artur Janc <aaj@google.com>, Christoph Kerschbaumer <ckerschbaumer@mozilla.com>, Anne van Kesteren <annevk@annevk.nl>, "Hodges, Jeff" <jeff.hodges@paypal.com>, W3C Web App Security WG <public-webappsec@w3.org>, Craig Francis <craig.francis@gmail.com>
Friendly ping. :)


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
Received on Tuesday, 13 September 2016 19:28:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:57 UTC