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

Re: CSP2: Drop 'unsafe-redirect'.

From: Mike West <mkwst@google.com>
Date: Thu, 2 Jul 2015 12:24:23 +0200
Message-ID: <CAKXHy=fqUs1vs44htdfJeOzCMvdciKJV+Tapkn2d_eh8HtFN8w@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
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 12:03 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

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

Actually, you know what: you're right. I forgot that we changed this
behavior as well: the report ought to contain the initially requested URL,
rather than the URL on which the request finally landed (see
http://www.w3.org/TR/CSP2/#violation-report-blocked-uri). I know Chrome
doesn't do this yet, but it ought to. I should also have listed it in the
breaking changes section of the spec. I'll add that now.


Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Thursday, 2 July 2015 10:25:15 UTC

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