I was surprised to hear from this Reuters video that it was possible for a page loaded on one tab to access and/or inject data onto another page loaded on a different tab.

TL;DW (too lazy; didn't watch) The interviewee in the video suggests that when doing online banking, the user exit his browser (thus closing all windows) and start a new browser session with just your banking page/tab open. Allegedly, malicious sites can check if you have your banking site open and inject commands onto those sites.

Can someone confirm and/or deny this claim? Is it only possible even if there is not parent/child relationship between windows/tabs?

3 Answers 3


Very common implementation is sharing sessions in the same process. E.g: you are logged into your bank account in tab A. When you copy the URL and paste it in the tab B (of the same browser-window), then: you are still logged in. The situation should be different when you start another process of your browser and paste the URL into another browser-window.

Does it mean, that website A opened in tab A has access to the session from any other tab? The answer is simple: no, because of the same origin policy. Malicious websites cannot interfere with other websites (even there are opened in nearby tabs).

Another idea could be stealing data/content from website opened in tab A via XMLHttpRequest. XMLHttpRequest opens the link to our bank, scans for sensitive content and sends it to the attacker. Well, this scenario is still fictitious. Why? The same answer here: same origin policy again. However, there is a possibility to increase the chance of success in this scenario (e.g Zone Policy in IE or MSXML 3.0 [http/https]), but IMO it's still very unlikely.

Well, the main danger which should be mentioned in this context are:

  • CSRF
  • Tabnapping


Let's look at a simple scenario. You are logged into your bank, which has no CSRF-protection. Meanwhile you switch to another tab (or even close your tab with the website of your bank - the most important here is that you didn't log out, your session wasn't destroyed and it says that you are still logged in). Another tab sends HTTP requests to your bank. As website has no idea if reqests are generated by script or by human, it accepts them. So unauthorized commands/requests were transmitted to your bank.


It's pretty new kind of phishing attack. There is a JS-script put on normal-looking site which detects if your tab is active (focused) or not. You switch to another tab. Then JS replaces the favicon and title (now they look the same as your bank's favicon and title). When you click back on the fake tab - you will see changed content (which looks the same as the website of your bank).

  • 2
    I've never heard of CSRF before and it sounds like an awfully dangerous vulnerability. Does mitigating CSRF-based attacks depend largely on the implementation of the sessioning system of the website rather than on the user?
    – jairo
    Jul 6, 2012 at 19:38
  • @jairo No, it depends on the browser. I believe Chrome / Firefox will block such a request because it detects that "mybank.hackersite.com" is trying to send a XmlHTTPRequest to "mybank.com", which is a different domain name (see the "same origin policy" stuff). Jul 6, 2012 at 21:40
  • 1
    Browsers have nothing to do here, 'cos HTTP POST and HTTP GET haven't got SOP restrictions. CSRF depends on WebApps' implementations (pretty common protections are: tokens, checking referrers and so on).
    – p____h
    Jul 7, 2012 at 16:08
  • 1
    @jairo, To answer your question: Yes, that is right. Preventing CSRF is up to the bank website, not up to the browser. (Darth Android's answer is incorrect. The browser cannot stop CSRF. The same-origin policy does not stop CSRF attacks. This is not browser-dependent.) However, CSRF is well-known and I would fully expect that your bank will almost certainly have implemented techniques to prevent CSRF attacks. (While vulnerabilities are always possible, it would be pretty appalling to find a bank that had not applied any defense against CSRF.)
    – D.W.
    Jul 11, 2012 at 16:42

This depends largely upon implementation and security measures in place by the browser. In reality? Chrome or Firefox or Opera will probably prevent this kind of attack. It used to be an issue years ago, but generally now it is not. Could it still happen? Potentially. It would require finding a security bug in the browser and exploiting it to do this, though.

Chrome by default groups parent/child tabs in the same tab process, but each tab group runs in isolated, sandboxed processes specifically to prevent this kind of issue. I believe Firefox and Opera have similar security measures in place, but don't know enough to comment in-depth.

If this is something you worry about and you're using chrome, simply create a new private browsing window (Ctrl+Shift+N) and do your banking there. This will cause chrome to spawn a new, isolated tab process, and all extensions are disabled by default in private browsing mode, which means the only javascript that is running with access to the information is stuff from the banking website itself.

  • I don't generally worry about this, and it sounds like I don't need to start either. Based on what you said, it sounds like modern browsers (or at least Chrome, Firefox and Opera) address this issue in the way they handle their processes and tabs. Would it be fair to say that the interviewee's suggestion in the video is baseless ...or out-dated, at best?
    – jairo
    Jul 6, 2012 at 19:34
  • @jairo It's far from baseless, as "cross-site scripting attacks" were fairly common a few years back. I'd say that the concerns are growing on out-dated as the web has changed and adapted to protect against them, but the problems are still useful to know and understand. I haven't had a chance to actually watch the video yet. Jul 6, 2012 at 21:42
  • What has "sandboxing" to do with "isolation"? Sandboxed processes are not isolated!
    – curiousguy
    Jul 8, 2012 at 3:01

The advice in the video is not total nonsense, though it wouldn't be something I'd emphasize to my friends or family. However, the explanation in the video is potentially a bit confusing.

Browsers are specifically designed to try to prevent a page in one tab from attacking a page open in another tab (assuming they are from two different domains). The specific security mechanism is known as the same-origin policy. So, generally speaking, you can usually assume that a page open in one tab cannot attack another site open in another tab. However, there are two important exceptions:

  1. If the browser has a vulnerability, then all bets are off. If the browser has an unpatched vulnerability, a malicious page in one page might be able to exploit the vulnerability, gain control of the browser, and then attack the other page.

    Browser vendors do their best to avoid vulnerabilities like this, but sometimes it happens. If you are using a modern browser (the latest version of Chrome, Firefox, or IE), such vulnerabilities should be relatively rare. If you are using an older version, oh boy, you could be in trouble.

    Shutting down your browser and starting it up with just the bank site loaded doesn't help defend against this sort of attack.

  2. If the web site has a vulnerability, then it might be susceptible to this sort of attack. Suppose the banking site, bank.com, has a particular kind of vulnerability known as a cross-site request forgery (CSRF) vulnerability. Then if you have a bank.com page open in one tab and a page from evil.com open in another tab, the page from evil.com could attack your banking session by exploiting the CSRF vulnerability in the bank's site.

    Hopefully, any reasonable online banking site should be designed to avoid CSRF vulnerabilities, so hopefully this should be rare for high-security sites. However, it does happen. (And it is much more common for low-grade sites.)

    Shutting down your browser and starting it up with just your bank loaded does defend against this sort of attack.

So, if you take all of this into account -- odds are, you probably don't need to do this business about shutting down your browser and starting it up with just your bank site. I realize there are some circumstances where it could possibly help, but they are pretty limited.

If you asked me for advice about how to ensure online banking is safe, here's what I'd suggest. If you are a consumer:

  • Choose a bank that promises to make you whole, in the event of fraud or unauthorized transactions. In the US, most banks have this policy for consumer accounts.

  • Turn on automatic updates on your operating system. Make sure you keep your OS updated.

  • Choose a modern browser, and keep it updated (most browsers will automatically update themselves these days). If you want to be especially paranoid, Chrome has a good reputation for security.

  • Choose a hard-to-guess password.

  • On Windows, install an antivirus program (there are reasonable free A/V products).

And that's it. If you want to be extra-cautious, you could take some extra steps: install Secunia PSI and follow its recommendations; you could also boot into a Linux LiveCD for your online banking.

If you are a business, securing online banking is much harder, because banks usually won't reimburse you for fraud: if a bad guy steals all your money, too bad, you lose. You might want to ask yourself carefully whether you really need it. If you do, I suggest using a number of paranoid steps: boot into a LiveCD each time you need to do online banking; establish transaction limits with your bank; consider enabling two-factor authentication, like one that uses a RSA SecurID or your mobile phone to confirm transactions; consider buying a separate machine that you use only for online banking and nothing else (not email, not web browsing, nothing else).

  • The advice in the video is not total nonsense. Thanks, it sounded like bologna to me as well. I understand that browser could have vulnerabilities and websites too, but in generally, having multiple tabs open does not pose a threat. (i don't have enough reputation to upvote your response, but I would if I could)
    – jairo
    Jul 11, 2012 at 14:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .