W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2015

Re: [CSP3] Question on the use case of the CSP request header

From: Brad Hill <hillbrad@gmail.com>
Date: Fri, 15 May 2015 18:49:35 +0000
Message-ID: <CAEeYn8geX8NGptWHSvFCwr_Yj697gqg9Muq+S6hR2CfZguNZdQ@mail.gmail.com>
To: 寒蕊 <hanrui.gao@gmail.com>, public-webappsec@w3.org
If a CSP policy is present, the user agent will always send the hint with
requests from that resource. The resource doesn't get a choice.   If the
resource doesn't set a CSP, the side-channel (of noticing whether a
redirect was blocked or not based on such a policy) is gone, and with it
the potential information leak.

On Fri, May 15, 2015 at 4:01 AM 寒蕊 <hanrui.gao@gmail.com> wrote:

> Hey guys,
> I am really confused by the use case that listed in the CSP3 doc[
> https://w3c.github.io/webappsec/specs/content-security-policy/#csp-request-header
> ].
> Let me cite the use case here:
> Note: The central reason for including this header is that it hints to a
> server that information about redirects might be leaked as a side-effect of
> a page’s active policy. If this header is present, a server might decline
> to redirect a logged-out user from example.com toaccounts.example.com,
> for example, as a malicious embedder might otherwise be able to determine
> the user’s logged-in status.
> I could not understand that if the embedder is malicious, why would it
> contain such an CSP header? I think if the embedder wants to get some
> important information (like log-in status) of another site, it can just
> drop the CSP header of itself, so that the browser would not send any
> resource request with the CSP request header.
> Any comments?
> Thanks!
Received on Friday, 15 May 2015 18:50:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:49 UTC