W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2014

Re: Remove paths from CSP?

From: Mike West <mkwst@google.com>
Date: Mon, 24 Feb 2014 14:50:37 +0100
Message-ID: <CAKXHy=cO4Rtn1RcOjqeqCaAP3CEB3HaUOY14H4AbzjG7-j7wvg@mail.gmail.com>
To: Sigbjørn Vik <sigbjorn@opera.com>, Dan Veditz <dveditz@mozilla.com>, Egor Homakov <homakov@gmail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Thank you for summarizing your take aways from the thread, this is
incredibly helpful.

On Wed, Feb 19, 2014 at 10:05 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:
> There are at least three proposals to fix this:
> a) Remove paths.
> Pro: This removes the worst offender.
> Con: Redirection domains are still leaked. This removes a useful feature.
> b) Only consider the first URL, do not block resources based on the
> redirected-to URLs.
> Pro: Removes all leakage.
> Con: Lots of open redirects exist, any such allowed by CSP would render
> the protection useless.

Egor's suggestion is a variant of B: only consider the first URL when
processing source expressions with a path, while continuing to apply
path-less source expressions to redirects.

That is, `script-src https://example.com
https://evil.com/thegoodbits/`would block `
example.com/redirect` -> `evil.com/evil`, but allow `
evil.com/thegoodbits/redirect` -> `evil.com/evil`. The latter seems an
unlikely enough risk to be worth accepting.

c) Don't leak cross domain information to the originator. (Remove
> report-uri, and pretend the resource loaded as normal.)
> Pro: Removes all leakage.
> Con: Removes debugging features. The most complex to implement.

Honestly, I don't believe that C is implementable. There are too many side

I think Egor's B` is the best of these options.


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.)
Received on Monday, 24 February 2014 13:51:26 UTC

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