Re: CSP: Problems with referrer and reflected-xss

(whoops, errant premature click on send)

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

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

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

Just another angle to consider.

-Brad

On Thu, Jun 12, 2014 at 9:23 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:
>
>
> On Thu, Jun 12, 2014 at 6:54 PM, Glenn Adams <glenn@skynav.com> wrote:
>> +1
>>
>>
>> On Thu, Jun 12, 2014 at 6:12 PM, Brian Smith <brian@briansmith.org> wrote:
>>>
>>> Hi,
>>>
>>> I just recently read the proposed specification for CSP referrer at [1]
>>> and I think it is problematic for several reasons.
>>>
>>> First, let's remember what the introduction of the spec says: "This
>>> document defines Content Security Policy, a mechanism web applications can
>>> use to mitigate a broad class of content injection vulnerabilities, such as
>>> cross-site scripting (XSS). Content Security Policy is a declarative policy
>>> that lets the authors (or server administrators) of a web application inform
>>> the client about the sources from which the application expects to load
>>> resources."
>>>
>>> I suspect that this introductory text actually needs to be updated since
>>> CSP does more than just restrict the sources of resource loads. However, the
>>> intent is still clear: CSP is a mechanism for *adding* limits what the
>>> content of the page can do. In particular, I think it is dangerous to add
>>> features to CSP that cause a CSP policy to *remove* limits on what the page
>>> can do. That is, adding a CSP policy to a page should never make the page
>>> less safe than if the CSP policy wasn't there. I think this should be
>>> considered a fundamental design constraint for all CSP features, and
>>> CSP-like features that violate this constraint should be defined in a
>>> *different* header field.
>>>
>>> However, the CSP referrer mechanism defined in the CSP 1.1 draft does
>>> violate this constraint, by allowing the CSP policy to specify that more
>>> referrer information should be leaked than the browser would normally do by
>>> default.
>>>
>>> Instead of determining what the final referrer should be, the CSP referrer
>>> should instead define the *maximum* amount of information that the referrer
>>> can contain. For example, if the CSP referrer policy was "origin" then a
>>> browser would never send more than the origin in a referrer header, but it
>>> might send less (none), e.g. for HTTPS-to-HTTP navigations. Then,
>>> "unsafe-url" would never be unsafe and it could be replaced with "default"
>>> since the effect would be "no change." Similarly, "none-when-downgrade"
>>> would be equivalent to the default and so it could/should be removed.
>>>
>>> There is a similar issue for reflected-xss: allow. This shouldn't be part
>>> of the Content-Security-Policy header, but rather part of another header.
>>>
>>> Again, my point is that that the Content-Security-Policy header should
>>> only *increase* the security of a page and *never* decrease the security of
>>> the page. Otherwise, we'll soon need a
>>> Content-Security-Policy-Security-Policy header to restrict what the
>>> Content-Security-Policy header can do.
>>>
>>> [1]
>>> https://w3c.github.io/webappsec/specs/content-security-policy/#directive-referrer
>>>
>>> Cheers,
>>> Brian
>>>
>>

Received on Friday, 13 June 2014 04:30:38 UTC