ブラウザとタブ間の情報転送
Webページが同じブラウザ内の他のタブ、または他のブラウザで開いている他のWebページが実行または送信していることを検出またはその他の方法で認識することは可能ですか？
私はCookieと、ローカルで使用するためにWeb開発者が配置した情報を保存するCookieの機能をよく知っています。この link と link も役に立ちましたが、Chromeは特に好きではありません。拡張機能について尋ねるだけではありません。私は侵害されたマシンまたはブラウザを使用すると、何でも可能であることも認識しています。
私の懸念は、広範囲にわたる情報収集（合法またはその他）を促進するマーケティングおよびその他すべての理由により、Webサイトがブラウザの外部に到達することにより、あらゆる使用に関する情報を収集することを試みることが望ましい場合があることです。タブ、いわばサンドボックス化されたタブでは、これはありそうにありませんが、（まだ発見されていなければ）これを回避する方法があると確信しています。これは間違いなく悪意があり、企業が定期的にこれを行うことは違法であると考えられますが、これは多くの企業が利益を得る、またはユーザーの無知を利用するためにできることすべてを実行することを止めていません。明確にするために：私は、ユーザーのブラウザの本格的なリアルタイムのアクティブなハッキングについて言及していません。いわばデータの「漏えい」です。
ソフトウェアの中心部分（ブラウザ）が何らかの種類のクロストークを許可するのではないかと恐れて、あるブラウザでバンキングを行い、別のブラウザで買い物をすることを好む場合があります。これは不要かもしれません。これが不可能な場合は、サンドボックス化に加えて、ブラウザー内にどのような保護手段が講じられているかを説明してください。可能な場合はソフトウェアレベルの詳細、または上記で投稿したリンクに加えて関連するその他のものを探していますが、これを StackO などの別のSEサイトに投稿したくありません。ありがとうございました。
ここには多くの視野があるため、答えるのは難しいです。
短い答え：
私はあなたの銀行を例として使用します。
たとえば、新しいタブを開いてyour-bank.comに入力したとします。
銀行が他のタブと通信するためのコードを明示的に開発していない場合、他のタブはあなたが銀行を閲覧しているとは言えず、そこで何をしているか。*
[〜＃〜] except [〜＃〜]悪意のあるタブがブラウザエクスプロイトを使用している場合（0日）、これは非常に高価でまれですそして非常に違法です。
- 他のサイトからyour-bank.comをクリックしたとは考えていません。また、コンピューターにブラウザー拡張機能/プラグインまたはマルウェアがないと考えています。
（...）サンドボックス化に加えて、ブラウザ内にどのような保護手段が配置されているか説明してください
Same-Originポリシー（SOP）：
「コンピューティングでは、同一起源ポリシーはWebアプリケーションセキュリティモデルの重要な概念です。このポリシーは、同じサイトから発信されたページで実行されるスクリプトを許可します-スキーム、ホスト名、およびポート番号の組み合わせ 1 = –特定の制限なしで相互のDOMにアクセスしますが、異なるサイトのDOMへのアクセスは禁止します。 1 サーバーがAccess-Control-Allow-Originを提供しない限り、同じ-OriginポリシーはXMLHttpRequestsにも適用されます（CORS）ヘッダー。特に、WebSocketは、同一オリジンポリシーの対象ではありません。
サーバーはHTTP Cookie情報に基づいて動作し、機密情報を明らかにしたり、状態変更アクションを実行したりするため、このメカニズムは、認証済みユーザーセッションを維持するためにHTTP Cookieに大きく依存する最新のWebアプリケーションにとって特に重要です。データの機密性または整合性の損失を防ぐために、無関係なサイトによって提供されるコンテンツ間の厳密な分離をクライアント側で維持する必要があります。」
ウィキペディアから（ http://en.wikipedia.org/wiki/Same-Origin_policy ）。
編集：
この投稿 に関する考慮事項（例としてもう一度銀行を使用します）：
document.domainメソッド
ここでは、subdomain.attacker.comがsubdomain.attacker.comおよびattacker.comと通信できると想定できます。しかし、subdomain.attacker.comがyour-bank.comと話したり、subdomain.your-bank.comと話したりすることは不可能です。
どうして？ attacker.comは、document.domainをyour-bank.comに設定できません。
クロスオリジンリソースシェアリングメソッド
ここではデフォルトで許可されていないため、銀行はattacker.comとのクロスオリジンリソースシェアリングを明示的に許可する必要があります。
脆弱なドメインの設定：
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, DELETE, PUT
window.postMessageメソッド（またはJSONPなど）
繰り返しになりますが、あなたの銀行はjavascript postMessageを介した通信を明示的に許可する必要があります。
私の結論：
同じ起源のポリシーは、今日、非常に信頼できますが、他のように、それは完璧ではありません。
ただし、ChromeまたはFirefox（U-XSSなど））の同じ起源のポリシー実装に欠陥を見つけた場合は、素敵な報酬を受け取ります。
そのため、バグを見つけるのは簡単ではありません。
MozillaおよびChromeバグバウンティプログラム：
http://www.google.com/about/appsecurity/chrome-rewards/
https://www.mozilla.org/en-US/security/bug-bounty/
古い同じ起源のポリシーの弱点に関する記事：
http://powerofcommunity.net/poc2008/kuza55.pdf
これは、タブ/ブラウザのクロストークを防止している唯一のブラウザ内メカニズム/防御ですか？
はい、それは（同じ起源のポリシー）クロス起源の話を防ぐための唯一のメカニズムです。
編集2：
上記で詳述したエクスプロイトは、ブラウザを閉じても持続しますか、それとも同時接続にのみ影響しますか？
両方とも！私たちは持続的で非持続的な悪用をすることができます。
Daniel Divriceanは この非永続的なエクスプロイト を3年前に報告しました。攻撃者は、銀行の残高など、他のサイトの情報を読み取る可能性がありますが、これは以前に銀行にログインしたことがある場合に限られます。この場合、悪意のあるサイトを閉じると攻撃が阻止されます。
1年前に この永続的なエクスプロイト をGoogleに報告しました。攻撃者はこれを使用して、ユーザーの操作や知識なしに、被害者のブラウザに悪意のある拡張機能をインストールする可能性があります。この場合、悪意のあるサイトを閉じても攻撃は阻止されません。
だから銀行のウェブサイトにログインする->ログアウト->ブラウザを閉じる->エクスプロイトサイトを開く->ブラウザを閉じる->銀行にログインする...今は安全？
安全であり、完全に安全ではありません。
Lucas NN の優れた答えに加えて、 Cross Site Request Forgery の脅威もあります。
CSRFでは、ブラウザで現在開いているタブがなくても、有効なセッションが必要です。 Facebookにログインしていて、FacebookにCSRFの脆弱性が含まれている場合、この脆弱性を悪用する悪質なサイトにアクセスすると、Facebookアカウントが侵害される可能性があります。これは、認証Cookieなどの認証メカニズムを通常のブラウザタブと共有しない別のブラウザまたはシークレットタブで機密サイトを開く場合に適しています。それでも、銀行のWebサイトがそのような攻撃に対して安全であることが期待されます。