Re: XSS-Protection notes

On Mon, Oct 10, 2016 at 11:01 AM, Artur Janc <aaj@google.com> wrote:

> Hey webappsec,
>
> I'm forwarding a short thread we had with Mike about the XSS-Protection
> proposal -- I tried to trim it down a bit, but apologies if it's still hard
> to follow. FWIW some of this is similar to the questions Dave raised on the
> parallel thread (https://lists.w3.org/Archives/Public/public-
> webappsec/2016Oct/0001.html).
>

Thanks for moving this out to the public list. :)


> From: Artur Janc <aaj@google.com>
>
>
>> > 1. I'm not entirely sold on the idea of having a different syntax for
>> CSP without giving developers additional useful functionality. Because of
>> missing browser support developers will have to either use both mechanisms
>> or have middleware which would reformulate XSS-Protection as CSP, at which
>> point they won't really need the simpler syntax.
>>
>> I agree with you, but I discount the importance of the objection, given
>> that 90% of pages don't have this problem, because they have no protection
>> in status quo. If we can get another 10% of pages using a simpler syntax,
>> that's a huge win for the web, even if it only works in Chrome.
>>
>
> But if you go through the effort to understand the benefits of the
> mechanism, apply nonces in your application and make sure everything works,
>

In an ideal world, I agree that this proposal would be superfluous. It
(intentionally) adds nothing on top of what already exists, and it's only
purpose is to layer a simpler syntax on top of CSP. My gut feeling is that
a simpler and more focused syntax is actually valuable, and will reduce
cognitive overhead for developers, which might make it more likely that
they'll invest the time to understand the benefits, and apply nonces/hashes.


> then if a simple string transformation is all you need to have it apply in
> all browsers, you'd probably just use regular CSP...
>

"All browsers" is a bit optimistic, isn't it? So far, one browser supports
`'strict-dynamic'`, and since I'm responsible for it, it's also the browser
that's most likely to also support this new mechanism if we can quickly
agree to how we'd like to spell it.

Moreover, given that the incremental effort from the browser side to
implement this proposal is pretty small, it seems like it might be a very
small group of browsers indeed that support the one but not the other.

> 2. Somewhat related, we'd need a few more things from CSP which aren't
>> currently in the proposal, e.g. 'unsafe-eval' and a Report-Only mode.
>>
>
>
> I thought you were getting away without eval? *sigh*
>>
>
> We use 'unsafe-eval' by default but we don't care because there are
> relatively few XSS-es in APIs allowed by eval(), etc and its wrappers. But
> yeah, it's pretty rare to be able to avoid it in our applications.
>

Sebastian and David raised similar arguments. It's not in the strawman
because I didn't even think about it, honestly. I agree that there's enough
`eval()` usage to make it something we probably need to allow. Added to the
strawman as a new `eval` member:
https://mikewest.github.io/artur-yes/#eval-member.


> If you need report-only, use CSP. :) That sounds glib, but really: 0.3% of
>> pages use a report-only policy. All sanity aside, it's a power-user
>> feature. (That said, it's trivial to add, so whatever.)
>>
>
> Hm, our data says something very different: out of the 1.6M domains with
> CSP, 70% use it as Report-Only. This is skewed by a couple apps deployed on
> hundreds of thousands of domains; but looking at unique policies it's still
> ~10%. The thing is that pretty much every app needs to do some testing
> before enabling enforcing mode, even if it's just for a short time, or in a
> staging environment. Having to "do it live" would be a fairly big
> restriction.
>

I suspect this is a difference between measuring "page views that send a
report-only policy" (
https://www.chromestatus.com/metrics/feature/timeline/popularity/16) and
"crawled domains that send a report-only policy". Or maybe I've just
screwed up the metrics in Chrome. *shrug*

In any event, you're right that it should be an option:
https://mikewest.github.io/artur-yes/#reportOnly-member


> > It's possible to add new fields to the JSON object but it will just end
>> up duplicating a lot of keywords from script-src. At some point it might
>> not be much more compelling than a CSP of "script-src 'nonce-foo'
>> 'strict-dynamic' 'unsafe-inline' https:; report-uri /foo".
>>
>> Aesthetics and ergonomics are compelling reasons to hide the current
>> syntax from developers.
>>
>
> But now we're introducing a new syntax which isn't really obvious, and
> bundles together parts of CSP and a weird under-specified XSS filter
> behavior. I could see the appeal of something like "Require-Script-Nonce:
> <nonce>" but I guess XSS-Protection does not seem all that much simpler...
>
> I guess I'm arguing for both more and less features at the same time; I'm
> not entirely sure what makes more sense ;-)
>

I think it would be helpful for you to argue for one or the other. I'm not
sure how many counterfactuals we can reasonably debate in this thread. :)

I think `{ 'nonce': 'abc', 'eval': 'unsafe-allow', 'report-to': 'whatever'
}` is both prettier and more comprehensible than `script-src http: https:
'unsafe-inline' 'unsafe-eval' 'nonce-abc' 'strict-dynamic'; report-to
whatever`. Explaining the latter requires substantial apology for
historical decisions and becomes more an exercise in cargo-culting than
deliberate choice through understanding.

We have an opportunity to hide the existing syntax behind a curtain. That
seems like a reasonable thing to do.

> 3. Blessing X-XSS-Protection by putting it in the new shiny thing sounds
>> a little anachronistic because it looks like XSS filters are on their last
>> legs (...)
>>
>
>
>> +tsepez, who will have opinions.
>>
>> 1. I think there's a big difference between "Google is going to turn off
>> the auditor." and "The auditor does more harm than good for most pages."
>> That said, I _would_ like us to change our default from filter to block
>> (and maybe remove the filter option entirely? :) ). Maybe this is a good
>> time to do that.
>>
>> 2. We need to write down the high-level behavior of `X-XSS-Protection`
>> somewhere. Might as well be here.
>>
>
> It seems to me that if we're trying to be forward-looking and build a
> prescriptive mechanism to help developers mitigate XSS, it's fine to omit
> parts of the platform that don't seem crucial. For example, XSS-Protection
> wouldn't include X-Content-Type-Options: nosniff or CSP whitelists even
> though they are arguably anti-XSS mechanisms.
>
> If XSS filters don't offer meaningful protection (which tends to be a
> fairly common view among security people) then I'm not sure the advantage
> of including them is worth the developer-facing complexity.
>

My primary goal here is to give developers a simple way to opt-into the
kinds of fairly strong assertions that the nascent "strict CSP
<https://security.googleblog.com/2016/09/reshaping-web-defenses-with-strict.html>"
crowd is pushing for, with a clearer focus than CSP, and without the
syntactic baggage. Whether the auditor's behavior should be included here
is a reasonable question. I think it's fairly clearly relevant to XSS
protection, and this seems like a good opportunity to change the default
behavior for the better.

But there wasn't much deliberate thought put into combining these things:
`XSS-Protection` just seemed like the best name for the thing. If there's a
better name (`Artur`?) without the larger implications, then it's certainly
worth talking about using it. :)

-mike