target="_blank" vulnerability

[anandgraves]

Did you search for similar issues before submitting this one?
Yes

Describe the issue you encountered:
A popup window or other tab can modify the location of it's window.opener even when the two windows have different domains.

See for more information:

• https://dev.to/ben/the-targetblank-vulnerability-by-example
• http://lists.w3.org/Archives/Public/public-whatwg-archive/2015Jan/0002.html

Expected behavior:
A popup window or tab shouldn't be able to modify the location of it's window.opener.

• Platform (Win7, 8, 10? macOS? Linux distro?):
  OS X 10.10.5
• Brave Version:
  0.11.6
• Steps to reproduce:
  1.Visit The Practical Dev Facebook page.
  2.Click the dev.to link in the profile. This opens a new tab or window.
  3.Observe that the original tab has migrated to this page.
  These steps are described at https://dev.to/ben/the-targetblank-vulnerability-by-example

[bbondy]

/cc @bridiver

[bridiver]

this affects Chrome, FF, Safari and probably all other browsers. I need to do a little research, but "fixing" this may actually violate web standards

[bridiver]

are there any legitimate uses for this? Maybe we should have a permission dialog for it?

[bsclifton]

@bridiver +1 on your proposal for a dialog. There are valid uses and it might be good to also be able to remember the choice (yes/no) for the domain.

One use-case I know of offhand was present in a ticketing system called ServiceDesk. It would pop up a new window where you'd search for an employee or similar and then hit enter or click OK. When you do, it manipulates the DOM on opener to set the value of an input box and the pop up then closes itself

[bridiver]

@bsclifton are they in different domains? There are certainly legitimate same-domain uses, but cross-domain seems a little more sketchy

[bsclifton]

no- same domain 😄

[diracdeltas]

This definitely is a major security issue for the cross-domain case, so I'm surprised it hasn't been addressed in the major browsers. IMO we should block cross-domain entirely and deal with breakage via a notification prompt only if it causes known issues. FWIW I have never observed a site doing this cross-domain.

[bridiver]

cross-domain write access to window.location is specifically allowed in the spec. I'm concerned that blocking by default could break legitimate sites and I think a permission dialog would be a better solution.

[bridiver]

I think the dialog should come up for same domain as well

[bsclifton]

I think we could offer two options (default choice TBD):

• Block access to window.opener completely
• Prompt for any attempts at window.opener, remember decision

Blocking most would protect most people. If that was the default, people with specific sites with valid use-cases (like my ServiceDesk example, or maybe their intranet, since it's trusted) will be affected and they'd have to know to disable it.

This might be a good time to put some thought into grouping all of the options we'll eventually have. Just a quick proposal - maybe we can offer a global "security level" you choose from? defaulted to what is effective for most folks

• don't enable FP
• show dialog for this window.opener
• don't have scripts blocked
• have HTTPS everywhere enabled
• ad/tracking protection enabled

And then you can scale up to the "I'm off the grid" option that enables all of the protections (or auto-dismissals for cases like this).

[luixxiul]

I guess the issue should be fixed with #10290 and #10424.

ref https://mathiasbynens.github.io/rel-noopener/

[luixxiul]

Closing as fixed with #10290 and #10424. They'll be available since 0.20.x.

[luixxiul]

no-qa-needed for this issue as QA is going to be done for #10290 and #10424.