Re: XSS-Protection notes

Here's another way to consider achieving the intended result...  There are
certainly some bits of configuration that have gelled over the years and
are now simply extra header cruft we might expect any reasonably secure
page to serve.
Some examples to consider:
  - X-Content-Type-Options=nosniff
  - The secure bit on cookies

With the move away from whitelists, best practice around CSP has changed
recently and may continue to change going forward.  So we might want to
avoid including CSP in any canonical security configuration.  Well, at
least today, in 2016.

Consider something like:
Security-Config: level=1; someConfigData=foo; otherConfigData=bar

Level 0 would be nothing.  (Same as not including this header.)
Level 1 would be whatever we define in 2016.
Level 2 would be whatever we decide to define in 2017.
...etc.

With this, developers could drop all the extra header cruft and follow more
simplified security guidance.  An opt-in model means that we avoid
automatically breaking pages.

We'd need to define a very clear philosophy about what we would include in
level=N+1.  Being too aggressive would hurt adoption, while being too lax
would pass on an opportunity to improve web security.  And of course we'd
need to define level=N+1 periodically, perhaps at an annual meeting on a
warm tropical island.  =)

Dave


On Mon, Oct 10, 2016 at 4:28 AM, Mike West <mkwst@google.com> wrote:

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