XSRF Error when link is opened via an <a> tag with target attribute set to "_blank"

Question

I've run into a peculiar bug that I have not faced before. I can provide any details that are needed but I'll try to be as generic as possible.

We have a intranet portal that links off to other applications on different domains. Every link on the portal page opens its corresponding application in a new tab via a target="_blank" in it's tag. One of these external applications is MS Exchange via Outlook Web App (OWA). This app's URL is https:// exchange. company.com OWA contains within it, a link which loads an iframe with content from https://exchange.company.com/ecp.

Here's the bug: If a user clicks the OWA link on the portal page, thus opening a new tab for it, that iframe contents fail to be pulled in. This is an excerpt from the error message the user receives:

Technical Information: Uncaught SecurityError: Blocked a frame with origin "https://exchange.company.com" from accessing a cross-origin frame.

This behavior is evident in the latest versions of Chrome and Firefox but is not present in the latest versions IE.

The weird thing is that the iframe loads 100% correctly if the user manually types the URL into their browser OR if the target="_blank" is removed from the tag.

To test, I tried making an intermediate page which contains solely a new-tab link to https:// exchange. company. com and then changing the portal's link to point to that page instead -- same bug.

I would think this is a security vulnerability that Chrome/FF have patched and the browser is, in fact, working as designed -- but, the wrench in this line of logic is "then why does it work without error when the user manually types in the URL or reaches the URL through an tag w/o target="_blank"? The iframe is on the same domain as the origin server (https:// exchange. company. com) so, as far as I understand, that should not result in a XSRF error.

I'm a LAMP/Drupal guy and I got pulled onto this because it came into our ticket system as a problem with our portal page. I've asked our Exchange admin for his insight and he, too, is at a loss. I'm planning to get the MS consultant that the systems team used to install Exchange on the phone to ask them about this but I was wondering if anyone here might have any ideas what could cause this. What data is maintained (or not maintained) by the browser when using a link with target="_blank" that is not maintained (or maintained) when opening said link in the same tab? Any advice is greatly appreciated. I'm at a loss on this one for now.

Thanks for reading.

EDIT: You may ask why we need to open Exchange in a new window -- let's just say it's a hard requirement. We use a SSO service that requires the user to completely close their browser post-logout so we have a convention for all portal links to open in a new tab so the original portal page remains open, reminding the user that they are still logged in. Since we have many shared-use workstations, if we allow Exchange to open in the same tab and a user closes Exchange, they may not realize they are still logged into the portal which may result in their session being hijacked by another user. By leaving the original portal window open at all times, at least the user is reminded that their session is still active as they go through closing their tabs at the end of the computer time.

That said, if anyone knows of another way to open a URL in a new tab that doesn't use target="_blank" (thus bypassing whatever the target="_blank" is doing that causes the bug), that would be a sufficient fix as well (although I would love to get to the root cause).

Answer 1

In my testing, Firefox 41 and Chrome 45 are affected; IE 11 and Safari 8 are not. I have not tested other versions of these browsers.

Apparently, when one page opens another in a new window/tab, they have some limited ability to interact with one another; in the child window, this is via the window.opener JavaScript object. [See "reverse tabnapping".] Somehow, however, Firefox and Chrome seem to get this crossed with the "origin" of this new window, which causes problems when e.g. OWA tries to open up and interact with its iframe on various Options pages. The issue is not specific to target="_blank", however: You can also effect a new tab/window by specifying a non-existent named target, e.g. target="newExchangeWindow", but doing so still results in the same behavior observed with target="_blank".

Interestingly, this behavior will persist across seemingly any number of intermediary pages: I can click a link that opens a new tab, browse around several different sites, and then navigate to our OWA, and the problem still exists -- it's not just an issue with links that open OWA itself in a new tab! It also cannot be solved by typing in the URL directly -- the tab remains "broken" seemingly for the entirety of its existence.

I've managed to find several ways that this can be solved:

Option 0:
Remove the target="_blank" from your links.
Obviously the downside is that this doesn't solve your requirement (nor mine), but at least your users can set their signatures and such!

Option 1:
Add rel="noreferrer" to your links:
<a href="https://exchange.company.com" target="_blank" rel="noreferrer">OWA</a>
This works in current versions of both Firefox and Chrome; I've seen suggestions that it won't work in Safari, although in my testing the original issue doesn't exist in Safari on the first place. Still, it may be an indication that this could be unreliable.

Option 2:
Clobber the window.opener object on an intermediary page, e.g.:

<html>
  <head><title>Clobbering window.opener...</title></head>
  <body onload="window.opener=null;window.location='https://exchange.company.com/'">
  </body>
</html>

Just to be clear, this intermediary page is what you would open with your target="_blank" link: Its job is to then clobber the window.opener object before taking the user on to OWA. You might want to add a meta-refresh tag and/or a link in the body just in case you get a user who's disabled JavaScript (but then again they won't be able to use OWA very well anyway...).

Option 3:
Clobber the window.opener object by injecting code directly into OWA.

It's not the easiest thing to do to inject code into OWA; in my case, since our OWA is behind a Big-Ip load balancer, I've written an iRule that actually replaces the </head> tag with <script type="text/javascript">window.opener = null;</script></head>. I only do this on the /ecp/ page itself, since that's where the issue lies, though one could do it on the /owa/ page since it's the "landing page" for everyone arriving in the app. Just be careful that you don't do it globally: There are several .js files that include that string as well, and trust me when I say that Bad Things® will happen if your replacement runs in those!

---

In my testing, again, Firefox and Chrome have this issue, but Safari and IE do not. (I did not test Opera because we don't have any users who use it.) In both of those browsers, any/all of these options are effective at remedying the problem. You could even use any combination of them together: The rel attribute can of course go on any/all of your links, and there's no harm in clobbering the window.opener object if it doesn't exist or has already been clobbered.