- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 2 Jul 2015 12:03:32 +0200
- To: Mike West <mkwst@google.com>
- Cc: Brian Smith <brian@briansmith.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Wendy Seltzer <wseltzer@w3.org>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>
On Thu, Jul 2, 2015 at 11:39 AM, Mike West <mkwst@google.com> wrote: > On Thu, Jul 2, 2015 at 11:35 AM, Anne van Kesteren <annevk@annevk.nl> wrote: >> Say I host evil.example. I allow images to be loaded from >> target.example exclusively through CSP. target.example uses >> credentials to redirect loads to username.target.example. Would >> evil.example not receive CSP reports with usernames extracted from >> target.example? > > 1. The changes in CSP2 prevent path leakage, but we don't have a mechanism > for preventing hostname leakage. The `CSP` header can allow the server to > mitigate the risk by deciding not to redirect in certain cases, but there's > no client side mitigation in place. It seems pretty bad that CSP reports introduced this kind of leak. Why would we reveal the target of the redirect? > 2. `unsafe-redirect` does not prevent this attack, as `evil.example` is in > control of the policy which governs redirect behavior. That is, > `evil.example`'s CSP will contain `unsafe-redirect`, the redirect will fire, > and `evil.example` will get a violation report. Sure, I was not really talking about unsafe-redirect anymore. More about CSP violating the security principles around redirects. -- https://annevankesteren.nl/
Received on Thursday, 2 July 2015 10:03:57 UTC