Re: CSP: Problems with referrer and reflected-xss

Thanks for the thoughtful response, Brian.

Two things before diving into the line-by-line:

1. After thinking about this some more, I don't really have a problem with
splitting directives out into a separate header if we can come up with a
clear way of bucketing things into one or the other. At the risk of being
reductive, do you have a proposal for a header name that would make sense
in opposition to `Content-Security-Policy`?

For the record, I fully agree with Chris's suggestion earlier in the thread
that HPKP would be _significantly_ better if it was part of HSTS. Having
two headers for one concept is a bad thing; I'd like to avoid it here.

2. The main thrust of your complaint seems to be directed towards
`referrer`. Note that since your original message, I've split out the
referrer policy definition into a separate spec (
https://w3c.github.io/webappsec/specs/referrer-policy/) which, among other
things, explicitly notes that "Nothing in this specification should be
interpreted as preventing user agents from offering options to users which
would change the information sent out via a `Referer` header" in
https://w3c.github.io/webappsec/specs/referrer-policy/#user-controls.

The CSP portion is really just a mechanism for delivering the policy
out-of-band with the document; it's necessary to do so for Twitter's use
case, as `t.co` doesn't serve an HTML document whose <meta> field could be
parsed, but instead redirects via a 301 response. Various other link
shortening services have similar needs.

With that in mind:

On Wed, Nov 5, 2014 at 2:12 AM, Brian Smith <brian@briansmith.org> wrote:

> Earlier in this thread, Mike West agreed that the document needs several
> editorial changes, to take into consideration that CSP is no longer just a
> mechanism to make web pages more secure, but potentially a mechanism to
> make web pages less secure.
>

I dropped the ball on that, thank you for the reminder. I'll look at
rewriting the introduction, and skim through the remainder to try to pick
out other places which should change. If you have specific suggestions,
please do send them over; that would be helpful.


> It isn't clear to me why the rules for sandbox and frame-ancestors are
> different from referrer and from the defaults for other directives. I
> accept that people want CSP to be simple, and that my suggestion of
> multiple header fields goes against simplicity, so my suggestion wasn't be
> taken. However, if we're aiming for simplicity, then the rules for
> combining multiple policies should still be simplified and made as
> consistent as possible--i.e. there should be as few rule-specific combining
> rules as possible. Note that Section 3.3, Section 3.5, and Section 10,
> explicitly and/or implicitly contradict each other and the
> directive-specific combining rules. If it isn't obvious how the
> specification is contradicting itself here, please reply (perhaps change
> the subject line), and I will point out all the contradictions I've found.
> I didn't point them out previously because I was hoping that my argument
> that CSP directives should be purely restrictive would result in these
> contradictions being corrected.
>

I'll fork this out, as it's a discussion I want to have, but will probably
take some time. :)


> As for reflected-xss, I honestly don't care about it too much. But, I feel
> obligated to point out that it is a specification for a W3C standard to
> restrict unspecified, proprietary mechanisms. (It might be instructive to
> attempt to write a conformance test suite for reflected-xss; I think it is
> impossible to do so.)
>

XSS protections exist in one form or another in WebKit, Blink/Opera, and
IE. While their inner workings are indeed proprietary, they've settled on a
de facto standard: the mechanism can be turned off entirely, or turned on
in either eliding or blocking mode. WebKit/Blink/Opera has added a
reporting mechanism, similar to CSP. I don't believe IE has done the same,
perhaps Kevin knows?

All questions aside as to the value of this mechanism, or the default
behaviors, representing the de facto standard in a new de jure CSP
directive seems like a reasonable way of making it clear what a site author
can do to work with modern browser's feature set. Stripping it out of the
spec wouldn't be an improvement over status quo.


> However, I still do care about improving the referrer directive. I still
> think it should work like the original CSP 1.0 directives, as a purely
> restrictive mechanism. Or, at the very least, I think that in the future
> there should be a new directive that specifies a cap on how much can be
> leaked by the Referer header, and I'm concerned that having both the
> current CSP Referrer and that new mechanism would be very confusing.
>

I'm more than willing to add language to either CSP or REFERRER to make it
clear that it's specifying a maximum, and that user agents should feel
encouraged to experiment.


> More generally, I've talked to multiple people in this working group and
> outside this working group about CSP Referrer and Referer in general. I've
> been pleasantly surprised how readily that everybody seems to agree that
> the current way browsers leak information with the Referer is not good. In
> particular, if browsers today did not send the Referer header, then
> everybody I've talked to seems to agree that we wouldn't accept a new
> proposal to specify and send the Referer header with as much information
> leaked as browsers currently do, and as much as CSP Referrer's "always"
> (and other) directives specify. That makes me question why we're rushing to
> fossilize and worsen this.
>

I suspect you've been talking to people who don't rely on the referrer
header for anything in particular. Advertisers, for instance, would
certainly disagree with your position. They might, for instance, suggest
that large sums of money rest on the back of the referrer header, and that
the `unsafe-url` policy simply allows a site to choose to align it's HTTPS
behavior with the behaviors they've come to expect from HTTP, thereby
removing one more barrier to migrating to a more secure web.


> For these reasons, even if you disagree with my original argument that all
> CSP directives should be purely restrictive, I still encourage you to push
> CSP Referrer back to CSP3 so that it can be improved. Particularly, I think
> seeing how Mozilla's experiments in restricting the Referer header could
> result in improvements to the mechanism, assuming Mozilla is still planning
> to experiment with improving the privacy aspects of Referer. Or, if Mozilla
> isn't going to do so, then perhaps others can take that on.
>

I think it's well worth experimenting with reducing the amount of
information we put into referrer headers by default. I hope the language in
the referrer policy spec already clearly allows that experimentation. If
you think that needs to be more clear, I'm happy to be more explicit.

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)