Fwd: XSS-Protection notes

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

Cheers,
-Artur

---------- Forwarded message ----------
From: Artur Janc <aaj@google.com>
Date: Sat, Oct 8, 2016 at 11:46 PM
Subject: Re: XSS-Protection notes
To: Mike West <mkwst@google.com>
Cc: Thomas Sepez <tsepez@google.com>, Krzysztof Kotowicz <koto@google.com>,
David Ross <drx@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,
then if a simple string transformation is all you need to have it apply in
all browsers, you'd probably just use regular CSP...


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


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


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


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

> 4. Precedence of headers. Will X-XSS-Protection be ignored by supporting
> UAs? If you have a semantically equivalent CSP for backwards-compatibility,
> will you get duplicate reports?
>


Currently, both would be applied via the combining logic in
> https://mikewest.github.io/artur-yes/#initialize-document-xss. Ignoring
> `X-XSS-Protection` is simpler, and probably equally valid (but we still
> need the combining logic for multiple `XSS-Protection` headers, so it
> doesn't buy us much in terms of complexity).
>