Re: CSP: Problems with referrer and reflected-xss

On Tue, Nov 4, 2014 at 3:03 PM, Brad Hill <hillbrad@gmail.com> wrote:

>  Just wanted to let you know we revisited this issue at the face to
> face meeting at TPAC, as part of closing out all last call comments
> for CSP Level 2.
>
>  The consensus of the group was to leave the specification as-is


First, thanks to the people that helped ensure my concerns were mentioned
in the meeting.

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. But, those changes haven't been made yet. For
example, the abstract in the document says "This document defines a policy
language used to declare a set of content restrictions for a web
resource[...]". This is no longer a good summary of CSP. Something along
the lines of "This document defines a policy language used to declare a set
of content restrictions for a web resource and/or disable default security
and privacy mechanisms[...]" would more accurately capture the intent of
the document. Note that the abstract isn't the only thing that needs to be
changed to take into account that CSP now is a way of reducing the security
of a web page; I only call it out explicitly as the first and most obvious
example. (Note: This paragraph probably comes across with a more negative
tone than I really intend. No snarkiness is intended.)


but
> to remove reflected-xss, report-uri, frame-ancestors and sandbox
> directives when a policy is set via a meta tag.
>

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.

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

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.

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.

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.

Cheers,
Brian