Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

On Fri, Dec 2, 2016 at 9:07 AM, Michael A. Peters wrote: > On 12/02/2016 08:47 AM, Boris Zbarsky wrote: >> >> On 12/2/16 11:34 AM, Michael A. Peters wrote: >>> >>> It seems that CSP behavior has radically changed since the last time I >>> looked at it >> >> >> I can't

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

On 12/02/2016 08:47 AM, Boris Zbarsky wrote: On 12/2/16 11:34 AM, Michael A. Peters wrote: It seems that CSP behavior has radically changed since the last time I looked at it I can't speak to when you last looked at it, but the current state shipping in browsers is, as far as I know, no

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

On 12/2/16 11:34 AM, Michael A. Peters wrote: It seems that CSP behavior has radically changed since the last time I looked at it I can't speak to when you last looked at it, but the current state shipping in browsers is, as far as I know, no different from what browsers shipped initially

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

On 12/02/2016 08:23 AM, Boris Zbarsky wrote: On 12/2/16 11:01 AM, Michael A. Peters wrote: Personally I love CSP but it does not allow inline scripts or inline CSS Only if you say to not allow them. The default behavior allows them. For example, this disallows inline scripts, because

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

On 12/2/16 11:23 AM, Boris Zbarsky wrote: (except for maybe with the new unsafe-inline option that requires checksum in the head ???) unsafe-inline doesn't require a checksum. See examples above. It's also not new. Certainly the November 2012 CR of CSP 1.0 [1] has unsafe-inline. -Boris

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

On 12/2/16 11:01 AM, Michael A. Peters wrote: Personally I love CSP but it does not allow inline scripts or inline CSS Only if you say to not allow them. The default behavior allows them. For example, this disallows inline scripts, because script-src is explicitly specified without

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

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

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

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 wrote: Thanks Michael. So to be safe one should use Edge?

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

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,

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

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

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

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 :-(

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

On 12/01/2016 06:14 PM, Elliott Sprehn wrote: On Wed, Nov 30, 2016 at 10:53 PM, Boris Zbarsky wrote: On 12/1/16 1:41 AM, Chris Holland wrote: I think the devil would be in implementation detail. Slapping a "rel/noopener" attribute on a specific link is very deterministic

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

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

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

On 12/01/2016 05:39 PM, Domenic Denicola wrote: From: whatwg [mailto:whatwg-boun...@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

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

On Wed, Nov 30, 2016 at 10:53 PM, Boris Zbarsky wrote: > On 12/1/16 1:41 AM, Chris Holland wrote: > >> I think the devil would be in implementation detail. Slapping a >> "rel/noopener" attribute on a specific link is very deterministic and >> straightforward from a logic

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

From: Zac Spitzer [mailto:zac.spit...@gmail.com] > how about rather than requiring this on every why not support a base tag > directive  for the whole document i.e. , similar to > ? Yes, this is a good idea to include in a general framework for imposing such

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

how about rather than requiring this on every why not support a base tag directive for the whole document i.e. , similar to ? On Fri, Dec 2, 2016 at 12:39 PM, Domenic Denicola wrote: > From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian > Hickson > > > I

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

From: whatwg [mailto:whatwg-boun...@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

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

On 12/1/16 1:41 AM, Chris Holland wrote: I think the devil would be in implementation detail. Slapping a "rel/noopener" attribute on a specific link is very deterministic and straightforward from a logic standpoint Whichever window was created from this link can't control the parent. It's

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

I guess this issue was discussed at the following thread on chromium.org, with comment #10 offering the more interesting exploit vector that seems to happen on sites with user-generated content (UGC): https://bugs.chromium.org/p/chromium/issues/detail?id=168988#c10 ... and Comment 11 right after

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

On 11/30/2016 06:21 PM, Michael A. Peters wrote: On 11/30/2016 05:23 PM, Ian Hickson wrote: On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters wrote: Right now the specification for window.opener() is seriously insecure, allowing for cross-domain script access by

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

On 11/30/2016 05:23 PM, Ian Hickson wrote: On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters wrote: Right now the specification for window.opener() is seriously insecure, allowing for cross-domain script access by default. I believe that's a bit of an