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).