Information Transfer Between Browsers and Tabs

Question

Is it possible for a webpage to detect or otherwise be aware of what other tabs in the same browser, or even other open webpages in other browsers are doing or transmitting?

I am well aware of cookies, and their ability to store information placed by the web dev for local use. This link and this link were also helpful, although I don't particularly like Chrome and I am not just asking about extensions. I am also aware that with a compromised machine or browser anything is possible.

My concern is that with marketing and all the other reasons that promote extensive information gathering (legitimate or otherwise), it may be desirable for a website to try and glean information about any and all usage by reaching outside of its browser's tab, so to speak. With sandboxed tabs, this seems unlikely, but I am sure there are ways around this (if not yet discovered). This would definitely be considered nefarious and possibly illegal for a company to be doing this regularly, but this hasn't stopped many companies from doing all that they can to gain an advantage, or take advantage of users' ignorance. TO BE CLEAR: I am not not referring to full-fledged real-time active hacking of a user's browser. Just data "leakage", so to speak.

Sometimes I prefer to do banking in one browser and shopping in another for fear that the central piece of software (the browser) may allow some type of crosstalk. I think this may be unnecessary. If this is not possible, please describe what safeguards are in place within the browser in addition to sandboxing. I am looking for software level details if possible, or anything else that is relevant in addition to the links I posted above... but didn't want to post this on another SE site such as the StackO. Thank you.

Answer 1

Hard to answer because we can have a lot of horizons here.

Short answer:

I will use your bank as an example.

Let's say you open a new tab and enter on your-bank.com.

If your bank has not explicitly developed any code to communicate with other tabs, no other tab could say that you are browsing your bank and what you are doing there.*

EXCEPT if a malicious tab is using a browser exploit (0-day), which is very expensive, rare and exceedingly illegal.

• I am not considering you clicked on your-bank.com through other site, and I am considering you don't have any browser extension/plugin or malware in your computer.

(...) please describe what safeguards are in place within the browser in addition to sandboxing

Same-origin policy (SOP):

"In computing, the same-origin policy is an important concept in the web application security model. The policy permits scripts running on pages originating from the same site – a combination of scheme, hostname, and port number1 – to access each other's DOM with no specific restrictions, but prevents access to DOM on different sites.1 The same-origin policy also applies to XMLHttpRequests unless the server provides an Access-Control-Allow-Origin (CORS) header. Notably, WebSockets are not subject to the same-origin policy.

This mechanism bears a particular significance for modern web applications that extensively depend on HTTP cookies to maintain authenticated user sessions, as servers act based on the HTTP cookie information to reveal sensitive information or take state-changing actions. A strict separation between content provided by unrelated sites must be maintained on the client side to prevent the loss of data confidentiality or integrity."

From Wikipedia (http://en.wikipedia.org/wiki/Same-origin_policy).

Edit:

Considerations about this post (I will use again your bank as an example):

The document.domain method

Here we can assume that subdomain.attacker.com can talk with subdomain.attacker.com AND attacker.com. But is impossible to subdomain.attacker.com talk with your-bank.com or even with subdomain.your-bank.com.

Why? attacker.com can not set its document.domain to your-bank.com.

The Cross-Origin Resource Sharing method

Here your bank needs to explicitly permits Cross-Origin Resource Sharing with attacker.com, because it is not permitted by default.

Settings of a vulnerable domain:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, DELETE, PUT

The window.postMessage method (or JSONP, etc.)

Again your bank needs explicitly permits communications through javascript postMessage.

My conclusions:

Same-origin policy is, nowadays, very reliable, but like anything, it is not flawless.

But if you could find any flaw in the same-origin policy implementation of Chrome or Firefox (like U-XSS, etc.), you will receive a nice reward.

So it is not easy to find a bug.

Mozilla and Chrome Bug Bounty Programs:

http://www.google.com/about/appsecurity/chrome-rewards/
https://www.mozilla.org/en-US/security/bug-bounty/

Article about some old same-origin policy weakness:

http://powerofcommunity.net/poc2008/kuza55.pdf

Is this the only in-browser mechanism/defense that is preventing tab/browser crosstalk?

Yes, it (Same-origin policy) is the only mechanism to prevent cross-origin talk.

Edit 2:

Are the exploits you detailed above persistant across browser closings, or do they only affect simultaneous connections?

Both! We can have persistent and nonpersistent exploits.

Daniel Divricean reported this nonpersistent exploit three years ago. An attacker could read informations of other sites, like your bank balance, but only if you had logged in your bank before. In this case, closing the malicious site would stop the attack.

I reported this persistent exploit to Google one year ago. An attacker could use it to install a malicious extension on the victim's browser, without user interaction and knowledge. In this case, closing the malicious site would NOT stop the attack.

So is logging into the bank website -> logging out -> closing browser -> opening exploit site -> closing browser -> logging into bank... now safe?

Is safer, not fully safe.

Answer 2

In addition to Lucas NN's excellent answer, there is also the threat of Cross Site Request Forgery.

CSRF does not require there to be a current tab open in the browser, only a valid session. So if you're logged into Facebook and Facebook happens to contain a CSRF vulnerability, and you happen to visit an evil site that exploits this vulnerability, your Facebook account could be compromised. This is a good case for opening sensitive sites in another browser or an incognito tab which does not share authentication mechanisms such as auth cookies with the normal browser tabs. Even so, the expectation is that a banking website would be secure against such attacks.