- From: Brad Hill <hillbrad@gmail.com>
- Date: Fri, 15 May 2015 18:49:35 +0000
- To: 寒蕊 <hanrui.gao@gmail.com>, public-webappsec@w3.org
- Message-ID: <CAEeYn8geX8NGptWHSvFCwr_Yj697gqg9Muq+S6hR2CfZguNZdQ@mail.gmail.com>
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