Re: CSP: Problems with referrer and reflected-xss

On Thu, Jun 12, 2014 at 9:30 PM, Brad Hill <hillbrad@gmail.com> wrote:

> I'd like to remind folks that one of the founding documents for this
> WG originally was Jeff Hodge's "web security framework requirements"
> document at the IETF:
>
> http://tools.ietf.org/html/draft-ietf-websec-framework-reqs-00
>

Thanks for that reminder. Re-reading that helps me understand your argument
better.


> One of the things that document calls out is the difficulty that
> developers have in understanding and applying a proliferating set of
> disjoint security mechanisms.  It called for, as much as was possible
> and practical, consolidating the various pieces of security policy
> into a unified and extensible framework, which CSP has become.
>

I don't think that consolidation is happening; look at Public-Key-Pins and
HSTS and CORS and many other things that are in separate header fields.
Public-Key-Pins was started after CSP was well established, so that's a
pretty good indicator that we're not going to be putting all new security
policy into the Content-Security-Policy header field. The fact is that
we're going to have to deal with multiple security header fields. I agree
though that we should avoid splitting things up superfluously.


> I appreciate the philosophy of "do no harm" as a CSP guiding
> principle, and perhaps that is a good razor for our coincident
> discussion on what to exclude from META policies.  But there is also
> real operational and practical harm from continuing the zoo of
> policies, X-headers and vendor-specific controls.  It's a nice way to
> inflate your findings count in a webapp security audit, but it's a
> pain for developers.
>

The "zoo" problem has more to deal with all of these things being defined
in separate documents and little to do with whether or not everything is in
one header (which, anyway, is not the case and won't be the case).


> And as many or all of the policies we are concerned with absorbing are
> also able to be set as headers, the "header injection" attack surface
> is little changed whether they are in CSP or a different header (with
> the exception I noted of META - although referrer is already defined
> as an injection-vulnerable meta tag...).
>

I disagree. If the Content-Security-Policy header is defined to be purely
restrictive, then there would be no problem with whitelisting that header
in "header injection" attack prevention in the HTTP layer and in HTML
<meta> land. And, it would also be a usability win by making CSP easier to
understand--especially it would make understanding <meta> easier, by making
it equivalent (modulo only reporting) to the HTTP header. IMO, that kind of
consistency is a much usability win than having everything in one header.

Cheers,
Brian