Google Chromeサイトへの認証を管理する方法は？
Chromeでは、すべてのタブが独自のプロセスです。しかし、Facebookなどのサイトへのログインは、複数のタブにわたって持続します。さらに言えば、多くの場合、OSを再起動しても保持されます。これは本質的に非常に安全ではないように見えますが、Chromeこれを実装していますか？特に再起動ということは、プロセスが終了した後でもセッショントークンのようなものを保存していることを意味します。これにより、認証済みの安全なサイトにシームレスに再接続できます。
Cookie付き！
Chromeは、他のブラウザと同様に、ファイルシステムにCookieを保存しています。これらのCookieを使用すると、一部のサイトに自動的に再接続できます。それはあなたのファイルシステムにあるので、リブートしてもそれらはまだそこにあります。複数のプロセスがあるかどうかはここでは関係ありません。
次に、Cookieが私のファイルシステムにある場合、どのページからもアクセスできるということでしょうか。
いいえ。 Cookieが作成されたページにのみアクセスできます。このポリシーを適用するのはブラウザです。ブラウザが正しく機能していれば、Cookieを適切なサイト（サーバー）にのみ送信するので問題ありません。
また、ファイルシステムを確認してCookieに直接アクセスすることもできますが、そのためにはオペレーティングシステムにアクセスする必要があります。 Webページはそれにアクセスできません。そのため、ブラウザーはそのためにその仕事をしており、読むことができるはずのCookieのみを提供します。
楽しいこと
クッキーを保護する必要があります。クッキーを盗むことは、パスワード/ユーザー名を盗むこととほとんど同じです。ウイルスのような誰かまたは何かがあなたのコンピュータに常駐するクッキーを盗むならば、あなたが現在ログインしているなら、それはそのウェブサイトであなたになりすますことができます。
Firebugなどのツールを使用して、Cookieを確認、編集、追加できます。したがって、偽の攻撃を仕掛けたい場合は、次のことができます。
- chromeを使用してWebサイトにログインする
- 開発者ツールを使用してchromeでCookieを読み取ります
- firebugでFirefoxを開き、Chromeで見つけた認証Cookieを追加します
その後、FirefoxとChromeでそのWebサイトにログインします。これはハックセッションハイジャックの単純化したバージョンです。必要に応じて、Cookieを別のコンピュータに転送できます。
このページから： http://blog.chromium.org/2008/09/multi-process-architecture.html
ブラウザーのタブ、ウィンドウ、および「クロム」を管理するブラウザープロセスは1つだけです。このプロセスは、ディスク、ネットワーク、ユーザー入力、および表示とのすべてのやり取りも処理しますが、Webからのコンテンツの解析やレンダリングは行いません。
そして、レンダラータブに関するセクションから：
各レンダラープロセスはサンドボックスで実行されます。つまり、ディスク、ネットワーク、またはディスプレイに直接アクセスすることはほとんどありません。ユーザー入力イベントやスクリーンペインティングなど、ウェブアプリとのすべてのやり取りは、ブラウザプロセスを経由する必要があります。これにより、ブラウザープロセスは、疑わしいアクティビティがないかレンダラーを監視し、エクスプロイトの発生が疑われる場合はレンダラーを強制終了します。
「ディスク、ネットワーク、ユーザー入力との相互作用」の部分にセッションCookieなどが含まれていると想定しています。
まず、Googleに固有のChromeがわかります この記事 は非常に便利です。CullenJはその前に言及しましたChromeはスレッドではなくプロセスを使用します。上記はリンクされている記事によると、Chromeはスレッドを使用してSQliteデータベース操作を処理し、Cookie操作の例を提供するため、Chromeは、SQLiteデータベースのどこかにCookieを保存します。
次の引用を見てみましょう：
ロックオブジェクトとスレッドセーフオブジェクトはお勧めしません。代わりに、オブジェクトは1つのスレッドのみに存在し、通信のためにスレッド間でメッセージを渡し、ほとんどのクロススレッドリクエストで（メッセージパッシングによって実装される）コールバックインターフェイスを使用します。
したがって、Googleはメッセージパッシングを使用していることを知っており、その詳細について [〜＃〜] ipc [〜＃〜] に関する情報を見つけることができます。
どの州：
Chromiumにはマルチプロセスアーキテクチャがあります。つまり、互いに通信する多くのプロセスがあります。主なプロセス間通信プリミティブは名前付きパイプです。 LinuxおよびOS Xでは、socketpair（）を使用します。名前付きパイプは、ブラウザープロセスとの通信用に各レンダラープロセスに割り当てられます。パイプは非同期モードで使用され、どちらの端もブロックされてもう一方の端を待機しないようにします。
ブラウザ内では、レンダラーとの通信は別のI/Oスレッドで行われます。次に、ビューとの間のメッセージをChannelProxyを使用してメインスレッドにプロキシする必要があります。このスキームの利点は、最も一般的でパフォーマンスが重要なメッセージであるリソースリクエスト（Webページなど）がI/Oスレッドで完全に処理され、ユーザーインターフェイスをブロックしないことです。これらは、RenderProcessHostによってチャネルに挿入されるChannelProxy :: MessageFilterを使用して行われます。このフィルターはI/Oスレッドで実行され、リソース要求メッセージをインターセプトし、それらをリソースディスパッチャーのホストに直接転送します。リソース読み込みの詳細については、マルチプロセスリソース読み込みをご覧ください。
各レンダラーには、通信を管理するスレッド（この場合はメインスレッド）もあり、レンダリングとほとんどの処理は別のスレッドで行われます（マルチプロセスアーキテクチャの図を参照）。ほとんどのメッセージは、メインのレンダラースレッドを介してブラウザーからWebKitスレッドに送信され、その逆も同様です。この追加のスレッドは、レンダラーからブラウザーへの同期メッセージをサポートするためのものです（以下の「同期メッセージ」を参照）。
名前付きパイプが何であるか疑問に思っていた場合 Wikipedia は次の定義を提供します。
名前付きパイプはシステムに永続的であり、プロセスの存続期間を超えて存在し、使用されなくなったら削除できます。プロセスは通常、名前付きパイプ（通常はファイルとして表示されます）に接続して、プロセス間通信を実行します。
マルチプロセスアーキテクチャに関するドキュメント から最後に1つ引用します。それは次のように読みます：
また、プロセスの総数が多すぎる場合、またはユーザーが既にそのドメインに移動したプロセスを開いている場合は、既存のプロセスに新しいタブを割り当てる方法もあります。
また、彼らのドキュメントの1つで、JavaScript互換性のために、サブドメインはルートドメインと同じドメインであると見なしていることを読みました。例：sub1.example.com、sub2.example.com、example.comは、Chromeでは同じドメインと見なされます。
したがって、これはchromeが正確に行う方法ではない可能性があります（ただし、ドキュメントに従ってさらに詳しく読むことができます）。しかし、これまで読んだ内容に基づいて、ブラウザを実装して、以下：
- Facebook.comを参照すると、ブラウザが新しいレンダラーを開始し、名前付きパイプを作成します
- ログインすると、レンダラーがデータベーススレッドにメッセージを送信してCookieを保存します
- 無関係なサイトをいくつか開くと、ブラウザがレンダラーとパイプをさらに作成します
- 何らかの理由で、facebook.comブラウザーに別のタブを開いて、ブラウザーが別のタブをレンダリングするためにfacebook.comをすでに開いているレンダラーにメッセージを送りたいと思っています。
- 新しいタブには、最初のfacebook.comタブで利用可能なすべての情報が含まれています。これは、プロセスを共有しているためです（私は、プロセスにCookieまたは何かを読み取るための独自のコピーを保存するので、データベーススレッドに煩わされる必要はありませんが、 Chromeがそうする）方法ではないかもしれません。
- サインアウトすることにした場合、データベーススレッドはCookieが変更されたことを確認し、データベースに書き込みます。サインインしたままの場合、データベースには触れません。
ここで、デフォルトのCookieの有効期間は、ブラウザが閉じたときに期限切れになることをここに追加する必要があります。そのため、ブラウザーを開いたり閉じたりしてサポートするために、Webサイトはこの存続期間をオーバーライドするように指示する必要があります（多くのサイトではそうしています）。
承知しました。ブラウザがCookieの有効期間を上書きすると、データベース（はい、ファイルシステム）に保存され、このサイトに戻ったときに再び読み込まれます。そこに保管するのは安全ですか？いいえ、コンピューターが危険にさらされておらず、OSが適切に機能している場合は例外です。
余談ですが、攻撃の検出とブロックにはオペレーティングシステムが採用されています。
別のブラウザに行く限り、それらはすべてCookieの保存に対して同様のことを行い、それが気になる場合はChromeのシークレットモードを使用するか、これを参照してください documentation は次のように述べています：
Google Chromeですべてのブラウザウィンドウを閉じたときにCookieを自動的に削除する場合は、[コンテンツの設定]ダイアログで[ブラウザを終了するまでローカルデータを保持する]チェックボックスをオンにします。特定のサイトのCookieがブラウザーを閉じるたびに削除されるように、例外。