Re: CSP2: Drop 'unsafe-redirect'.

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]

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

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

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.

<snip>


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

Like I said above, I'm skeptical that #5 is true.

It was already decided that the information leak was important enough to
make significant changes to the spec. As Mike pointed out, nobody expected
this to be even an issue, which is why it wasn't marked "at risk." Nobody
seems to be arguing that the specified behavior is bad; the argument seems
to be only about compatibility. So, like I said above, I think it's better
to find ways to minimize the risks of browsers complying with the spec,
than to change the spec.

If the mechanism is bad, that's another issue.

Cheers,
Brian

[1]
http://homakov.blogspot.de/2014/01/using-content-security-policy-for-evil.html
[2]
http://www.myseosolution.de/deanonymizing-facebook-users-by-csp-bruteforcing/