- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Tue, 25 Feb 2014 11:50:27 -0800
- 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