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 11:39:35 +0200
Message-ID: <CAKXHy=dRyazHMMaU3iYFA56k1gvS8SPhTgiqh+sfZrvVmk7Dcg@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 11:35 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Jul 2, 2015 at 10:25 AM, Mike West <mkwst@google.com> wrote:
> > No, `unsafe-redirect` does not protect against information leakage, if
> only
> > because a malicious page would simply opt-in. It gives a developer
> > marginally more control over the resources her site loads, but I'd put it
> > squarely in the nice-to-have category of features.
> Is that analysis correct?

Yes! :)

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

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.

Received on Thursday, 2 July 2015 09:40:23 UTC

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