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 10:25:36 +0200
Message-ID: <CAKXHy=dqFL793WasZDbcdDO97MCYA9OcPAt6ePjaV8X=_R2Yxw@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Wendy Seltzer <wseltzer@w3.org>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>
On Wed, Jul 1, 2015 at 8:24 PM, Brian Smith <brian@briansmith.org> wrote:

> On Wed, Jul 1, 2015 at 9:12 AM, Mike West <mkwst@google.com> wrote:
>> Neither Chrome nor Firefox have implemented the `unsafe-redirect` bits of
>> CSP2 (see 1.2 of http://www.w3.org/TR/CSP2/#changes-from-level-1).
>> Experimentation locally on internal sites leads me to believe that it's not
>> going to be web compatible: I didn't find any Google property that used CSP
>> which the new behavior wouldn't break in some way.
> > Moreover, statistics from Chrome show that about 0.7% of page views
> [use paths in CSP]

No, I think I was unclear here: 0.7% of page views involve loading
resources that are the results of redirects into a page governed by a CSP
(e.g. the page includes `<img src="/example">` which redirects to

If we began enforcing the behavior specified by `unsafe-redirect`, those
resource loads would be blocked until the pages added `unsafe-redirect` to
the relevant places in their policies.

> It would be interesting to know how much of that 0.7% are Google sites.

All I have is a raw count, but it's probably fair to say that a solid chunk
of that 0.7% is Facebook, Google, Twitter, etc.

> When Firefox implemented mixed content blocking, Mozilla treated
> Mozilla-owned sites specially: We assumed that our coworkers would make the
> necessary changes before we shipped, after we helped them understand what
> was necessary, and so we didn't consider breaking any Mozilla site a risk
> for shipping. That strategy worked very well for us (IIRC).

Point taken. That said, if I could wave a magic wand to make changes to
some subset of Google sites, this isn't what I'd focus my effort on. :)

> CSP was designed to make it extremely easy to make the changes that would
> unbreak a site that would break if the specified behavior were implemented.
> The 0.7% number would likely fall very rapidly if sites were given notice
> about the change. It is just a matter of putting unsafe-redirect in a few
> places to get the current behavior, right?


> Thus, it isn't clear to me that the spec needs to change due to
> compatibility concerns. Rather, it seems more likely that browsers just
> need to be careful about when and how they ship the change to comply with
> the spec.

That's a reasonable strategy to persuse; if the WG doesn't want to remove
the feature, then it's certainly what we'll need to do in order to ship the

> We didn't declare it as "at risk" in the CSP2 CR, though we probably
>> should have.
> I think it's important to give more context about this. My understanding
> of the presented argument is:
> 1. Somebody proposed removing path expressions from CSP, because of the
> information leak described at [1] and [2].
> 2. In order to mitigate the information leak, it was decided to disable
> redirects by default and to provide the unsafe-redirect mechanism to opt
> into the information leak.
> 3. Browsers never implemented the mitigation, but instead only shipped the
> old behavior with the information leak.
> 4. Because of #3, it would not be web-compatible to remove path
> expressions from CSP.
> 5. Because of #3, it would not be web-compatible to implement the
> compromise that was agreed to when it was decided to keep path expressions
> in CSP after the information leak was discovered.
> 6. Now it is too late to add any other new feature to CSP that would
> prevent the information leak.
> Is this correct?

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.

I believe we resolved the information leak you're pointing to by ignoring
path components of source expressions after a redirect, as described in
http://www.w3.org/TR/CSP2/#source-list-paths-and-redirects. I am not
proposing that we remove that mitigation; both Chrome and Firefox are
shipping it now, and it is indeed important to keep in the spec.

For clarity,
is the change I've made to the ED, and that I'd like to make to the CR
before moving forward.


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 08:26:26 UTC

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