Re: Remove paths from CSP?

On Wed, Feb 12, 2014 at 2:02 PM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> Well, right there is a problem. If a page author can tell if a
>  redirected-to third party resource fits a regexp or not, he can tell
> redirection chains of that third party resources. This is opening up a
> new hole in the same domain policy.
>

There is no regex matching capability in CSP. Path leakage is a brute-force
attack. Otherwise this is an accurate description of the problem I'd like
to address.

Given the prevalence of open redirects, I don't think we can reasonably
allow all redirects to bypass a page's CSP. Perhaps something like Egor's
suggestion to allow redirects for specific paths is a good compromise,
which limits the potential leakage to cross-origin redirects on an origin
(rather than path) basis.

> An issue is that leakage is inherent in the functionality: it isn't
> > possible to block an image from loading, for example, without making the
> > fact that the image was blocked visible to the page that loaded it.
>
> That should be fairly easy. Even if blocked, call onload, and return the
> image dimensions to the page. That is all a page can detect anyway.
>

How do we know the original image dimensions if we block the load?


> If CSP is to be at all valuable, it needs to avoid opening new security
> holes, not trade one security hole for another.


I agree with the sentiment.


> Especially not if the former is avoidable by good web site security
> practices, while the latter is not.
>

Theoretically, you're right: preventing content injection attacks is an
absolutely trivial problem. Practically, we're really bad at it,
collectively. If we were good at it, CSP would be fairly pointless. Since
we're not, I (with admitted bias) think it's quite valuable.

> I'd welcome proposals that would avoid this.
>
> Block disallowed resources from interacting with the page, but pretend
> to the page that they were loaded.
>

Pretending is difficult, particularly given that we, in the best case, want
to avoid making requests for blocked resources.

Moreover, perfectly pretending that we loaded the resource (e.g.
replicating all the side-effects of loading a resource, including layout
changes, script execution, etc) is indistinguishable from not blocking the
resource in the first place. If avoid some of the side-effects (e.g. we
don't want to execute blocked script), there will be detectable differences.

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

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