Re: CSP: Problems with referrer and reflected-xss

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:24:09 UTC