Re: CSP2: Drop 'unsafe-redirect'.

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
`/examples-are-awesome-really-yay.png`).

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

Yes.


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


> 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,
https://github.com/w3c/webappsec/commit/7456cb77e504fa70991b3cc54c852e62ebc7a2cc
is the change I've made to the ED, and that I'd like to make to the CR
before moving forward.

-mike

--
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
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)