- From: Michael A. Peters <mpeters@domblogger.net>
- Date: Fri, 2 Dec 2016 08:01:37 -0800
- To: whatwg@lists.whatwg.org
Personally I love CSP but it does not allow inline scripts or inline CSS and over 95% of the web makes heavy use of both. I believe there now are CSP parameters that relax those prohibitions but from I understand they are only relaxed when a hash of the inline scripts / CSS is declared in the head. Google Webmaster Tools including PageSpeed also heavily encourage all JavaScript being referenced at the end of the page so that it isn't above the fold and because they are Google, most of the masses believe that is best and will help with page search ranking and that too isn't compatible with CSP where the scripts need to be defined in the head (except for maybe with the new unsafe-inline option that requires checksum in the head ???) I don't know what the planned CSP option for window.opener() looks like, I just know that most websites break as soon as a CSP header is sent and it isn't always trivial to make them work. On 12/02/2016 05:01 AM, Jonathan Zuckerman wrote: > Could you elaborate on the point made earlier that CSP is too complicated > to implement? What would the fix for this particularly security hole look > like, using CSP? > > On Fri, Dec 2, 2016 at 1:11 AM Richard Maher <maherrj@googlemail.com> wrote: > > Thanks Michael. So to be safe one should use Edge? Who'd have thunk it? > > Anyone tested Michael's example on FireFox or Safari? > > It does look like Chrome is the driver of rel=noopener. Does the credential > API https://w3c.github.io/webappsec-credential-management/ rely on this > flaw? > > On Fri, Dec 2, 2016 at 11:44 AM, Michael A. Peters <mpeters@domblogger.net> > wrote: > >> If window.opener() did not work cross-domain then as far as I can tell >> that would be secure. >> >> >> On 12/01/2016 07:23 PM, Richard Maher wrote: >> >>> I see what you're saying Michael and also agree it's serious. Would I be >>> correct in thinking that MS Edge solves the problem by not returning >>> window.opener cross-domain? Is the UA not a logical and uniform place for >>> this? >>> >>> BTW I've also experienced the CitHub topic-closure nazis many times :-( >>> >>> >>> On Fri, Dec 2, 2016 at 10:42 AM, Michael A. Peters < >>> mpeters@domblogger.net> >>> wrote: >>> >>> Well if it was done as a header, I suppose it could be added as a >>>> http-equiv meta tag for those who want to. >>>> >>>> Header is the easiest solution to make sure it is applied everywhere >>>> without question. It could even be added at the front-end proxy to cover >>>> numerous web applications on many domains at once. >>>> >>>> And I know this is conspiracy theory, but that's why I think there is >>>> such >>>> resistance to it. >>>> >>>> Since the flaw is required for OAuth to work, companies invested in > OAuth >>>> and that profit from OAuth solutions don't want sites behind proxies > that >>>> would break OAuth and don't want webmasters to understand they have to >>>> reduce security in order to implement an OAuth solution. >>>> >>>> That's just a suspicion of mine, but I can't think of any other logical >>>> reason as to why a node attribute was chosen as the solution, and why >>>> there >>>> is such resistance to doing it the right way with a header. To me it > just >>>> doesn't make sense. >>>> >>>> >>>> On 12/01/2016 05:45 PM, Zac Spitzer wrote: >>>> >>>> how about rather than requiring this on every <a> why not support a base >>>>> tag directive >>>>> for the whole document i.e. <base rel="noopener">, similar to <base >>>>> target="_blank">? >>>>> >>>>> On Fri, Dec 2, 2016 at 12:39 PM, Domenic Denicola <d@domenic.me> wrote: >>>>> >>>>> From: whatwg [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Ian >>>>> >>>>>> Hickson >>>>>> >>>>>> I believe that's a bit of an overstatement. There are certainly risks >>>>>> >>>>>>> >>>>>>> involved in window.opener (they're briefly discussed in the spec >>>>>> itself), >>>>>> but it doesn't remove the origin checks. >>>>>> >>>>>> This is the crucial point. >>>>>> >>>>>> Whenever you are discussing a supposed security issue, you need to > make >>>>>> clear what the threat model is. That is: >>>>>> >>>>>> - What would be the impact on the victim if the security hole is taken >>>>>> advantage of? >>>>>> - Is this something we are trying to prevent on the web platform? >>>>>> >>>>>> In this case, the impact on the victim (a user of a web browser) is >>>>>> that >>>>>> they could click a link from page A to page B, which opens in a new > tab >>>>>> (tab B). Then, tab A could be navigated to a new URL, instead of >>>>>> staying >>>>>> on >>>>>> page A. >>>>>> >>>>>> This is not a big impact. Notably, page B is not able to read any of >>>>>> the >>>>>> content of page A, which might be sensitive. Page B is not able to >>>>>> interfere with the operation of any of page B's scripts. And > crucially, >>>>>> when page B navigates tab A to another page, the URL bar of tab A >>>>>> changes >>>>>> to indicate that. >>>>>> >>>>>> There is no desired security guarantee on the platform that we want to >>>>>> prevent pages from directing users to "bad" sites. We count on users >>>>>> inspecting the URL bar to understand what page they are interacting >>>>>> with >>>>>> in >>>>>> a given tab. >>>>>> >>>>>> So, while it might be a bit surprising that suddenly tab A is >>>>>> navigating >>>>>> somewhere else, there is no security issue here, and users are not >>>>>> endangered in any way---at least, not in any more danger than they >>>>>> already >>>>>> are from browsing the web without looking at their URL bar to see > where >>>>>> they've ended up at. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>
Received on Friday, 2 December 2016 16:02:12 UTC