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

Re: Remove paths from CSP?

From: Daniel Veditz <dveditz@mozilla.com>
Date: Tue, 25 Feb 2014 11:50:27 -0800
Message-ID: <530CF403.7000103@mozilla.com>
To: Mike West <mkwst@google.com>, Sigbjørn Vik <sigbjorn@opera.com>, Egor Homakov <homakov@gmail.com>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
On 2/24/2014 5:50 AM, Mike West wrote:
> 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.

I don't understand the proposal and example. Why is the first one 
blocked? Isn't evil.com/evil a pathless match for evil.com? Is the 
second one allowed because it's same-origin?

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

I agree for the second part (pretend it loaded), but we could do the 
first (don't report on blocked redirects) if reporting anything at 
all--like the original in-page URL--is considered too revealing.

-Dan Veditz
Received on Tuesday, 25 February 2014 19:50:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC