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.
![](../../users/profiles/8340.webp)
- 33,408
- 6
- 67
- 178
![](../../users/profiles/61842.webp)
- 513
- 6
- 13
-
"Between browsers" should be disambiguated. Chrome to Firefox is one interpretation. A Firefox process launched by the operating system and another Firefox process launched the same way is another interpretation. – H2ONaCl May 20 '19 at 10:49
2 Answers
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.
-
-
-
-
One more time ^_^: "has not **explicit** developed" -> "has not **explicitly** developed" ? – Dec 03 '14 at 02:45
-
-
And you had it in bold! Oh, now I like @Ricky. This has turned out to be a lesson for both of us, hasn't it @Lucas? If only i knew my question would serve so much purpose. Thank you both. – user58446 Dec 03 '14 at 04:25
-
@user58446 For sure, I learned a lot here. If you believe my answer solves your problem, please select it as the right answer, this will help others in the future. =) – Lucas NN Dec 03 '14 at 04:33
-
2Soon, but not so fast: In light of [this post](http://stackoverflow.com/questions/3076414/ways-to-circumvent-the-same-origin-policy), it seems that the same-origin policy cannot be trusted, or at least would seem to be difficult for me as a user to keep track of. Also, it seems to be routinely circumvented by WebDevs in legitimate cases for functionality. Is this the only in-browser mechanism/defense that is preventing tab/browser crosstalk? – user58446 Dec 03 '14 at 04:35
-
-
2I believe same-origin policy is indeed what I was looking for. And you answered my next question: It says there is no specification for this policy, so it is conceivable that some browsers may do this better than others. But if they are paying people to find vulnerabilities, then I suppose that I can't ask for much more beyond designing my own browser. Answer awarded. – user58446 Dec 03 '14 at 05:19
-
1@user58446 You can read this (old) article (http://powerofcommunity.net/poc2008/kuza55.pdf). Chrome and Mozilla are doing a great job with their Bug Bounty Programs. I am an active participant. – Lucas NN Dec 03 '14 at 05:28
-
Thank you again. Don't forget, use 'a' if the next word begins with a consonant. Use 'an' if the next word begins with a vowel. "I am a active participant" -> "I am an active participant". You got it right in your answer with "I will use your bank as an example", and was mildly impressed until I saw this latest mistake :) – user58446 Dec 03 '14 at 05:34
-
2@Ric: Just edit the question and the author will get chance to review it if you see any minor typos or grammatical errors like that. ;-) – SilverlightFox Dec 04 '14 at 10:24
-
2I'm so sorry, this will be my final question: Are the exploits you detailed above persistant across browser closings, or do they only affect simultaneous connections? My question is not really asking about a full persistent compromise of the machine by a website (ie. a backdoor install). I generally follow safe browsing habits, but I don't always know where I will land. This is why I do not open secure sites AND do general browsing AT THE SAME TIME. So is logging into the bank website -> logging out -> closing browser -> opening exploit site -> closing browser -> logging into bank... now safe? – user58446 Dec 04 '14 at 16:03
-
@LucasNN - I forgot to tag you in my last appendage to the question. Please see previous comment. Thank you. – user58446 Dec 05 '14 at 01:02
-
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.
![](../../users/profiles/8340.webp)
- 33,408
- 6
- 67
- 178
-
1SilverlightFox, good point. XSRF is an important issue. @user58446 Study about XSRF too. This is not a browser issue, is a vulnerability in the website itself, is very common and can be very dangerous. – Lucas NN Dec 05 '14 at 07:29