用饼干！

与任何其他浏览器一样，Chrome 会在您的文件系统中存储一个 cookie。这些 cookie 使您能够自动重新连接到某些站点。由于它在您的文件系统中，即使您重新启动它们仍然存在。是否有多个进程在这里无关紧要。

那么你可能想知道，如果cookies在我的文件系统中，是否意味着任何页面都可以访问它们？

没有。只有为其创建 cookie 的页面才能访问它。执行此政策的是您的浏览器。如果您的浏览器正常工作，那么您就可以了，因为它只会将 cookie 发送到正确的站点（服务器）。

您还可以通过查看文件系统直接访问 cookie，但为此您需要访问操作系统。网页无权访问，因此浏览器正在为他们完成这项工作，并且只为他们提供他们应该能够读取的 cookie。

有趣的事

您需要保护您的 cookie。窃取您的 cookie 与窃取您的密码/用户名几乎相同。如果某人或某物（例如病毒）窃取了驻留在您计算机上的 cookie，如果您当前已登录，它可能会在该网站上冒充您。

您可以使用 firebug 等工具检查、编辑和添加 cookie。因此，如果您想发起虚假攻击，您可以：

• 使用 chrome 登录网站
• 使用开发者工具读取 chrome 中的 cookie
• 使用 firebug 打开 firefox 并添加您在 chrome 中找到的身份验证 cookie

然后，您将在 Firefox 和 chrome 中登录该网站。这是黑客会话劫持的简化版本。如果您愿意，您可以将 cookie 传输到另一台计算机上。

从这个页面： http: //blog.chromium.org/2008/09/multi-process-architecture.html

只有一个浏览器进程，它管理浏览器的选项卡、窗口和“chrome”。此过程还处理与磁盘、网络、用户输入和显示的所有交互，但它不会尝试解析或呈现来自 Web 的任何内容。

从关于渲染器选项卡的部分：

每个渲染器进程都在沙箱中运行，这意味着它几乎无法直接访问您的磁盘、网络或显示器。与 Web 应用程序的所有交互，包括用户输入事件和屏幕绘制，都必须经过浏览器进程。这让浏览器进程可以监视渲染器的可疑活动，如果它怀疑发生了漏洞，则将其杀死。

我假设“与磁盘、网络、用户输入的交互”部分包括会话 cookie 等。

首先，具体到谷歌浏览器你会发现这篇文章非常有用。CullenJ 之前提到 Chrome 使用进程而不是线程，但这是不正确的。它同时使用两者。根据上面链接的文章，Chrome 使用线程来处理 SQlite 数据库操作并给出了 cookie 操作的示例，因此我们可以假设 Chrome 将 cookie 存储在 SQLite 数据库中的某个地方。

现在让我们看一下下面的引用：

我们不鼓励锁定和线程安全的对象。相反，对象只存在于一个线程上，我们在线程之间传递消息以进行通信，并且我们对大多数跨线程请求使用回调接口（由消息传递实现）。

因此，我们知道 google 使用消息传递，我们可以在阅读IPC时找到更多关于它的信息。

其中指出：

Chromium 具有多进程架构，这意味着我们有很多进程相互通信。我们主要的进程间通信原语是命名管道。在 Linux 和 OS X 上，我们使用 socketpair()。为每个渲染器进程分配一个命名管道，用于与浏览器进程通信。管道以异步模式使用，以确保任何一端都不会被阻塞等待另一端。

在浏览器中，与渲染器的通信是在单独的 I/O 线程中完成的。进出视图的消息必须使用 ChannelProxy 代理到主线程。这种方案的优点是资源请求（对于网页等）是最常见和性能关键的消息，可以完全在 I/O 线程上处理，而不会阻塞用户界面。这些是通过使用由 RenderProcessHost 插入到通道中的 ChannelProxy::MessageFilter 来完成的。该过滤器运行在 I/O 线程中，拦截资源请求消息，并将其直接转发到资源调度程序主机。有关资源加载的更多信息，请参阅多进程资源加载。

每个渲染器还有一个管理通信的线程（在本例中为主线程），渲染和大部分处理发生在另一个线程上（参见多进程架构中的图表）。大多数消息通过主渲染器线程从浏览器发送到 WebKit 线程，反之亦然。这个额外的线程是为了支持同步渲染器到浏览器的消息（参见下面的“同步消息”）。

如果您想知道命名管道是什么，维基百科给出了以下定义：

命名管道是系统持久的，并且存在于进程生命周期之外，一旦不再使用就可以删除。进程通常附加到命名管道（通常显示为文件）以执行进程间通信。

现在，我想从处理多进程架构的文档中得到最后一句话。内容如下：

如果进程总数太大，或者如果用户已经打开一个导航到该域的进程，我们也有策略将新选项卡分配给现有进程。

我还在他们的一份文档中读到，他们认为子域与 JavaScript 兼容性的根域是同一个域。例如：sub1.example.com、sub2.example.com 和 example.com 被 Chrome 视为同一个域。

所以这可能不是 chrome 是如何做到的（但是，你可以在他们的文档之后进一步阅读它）但是，根据我到目前为止所读到的内容，我可以实现一个浏览器来执行以下操作：

1. 我浏览到 facebook.com，浏览器启动一个新的渲染器并创建一个命名管道
2. 我登录，渲染器向数据库线程发送一条消息以存储 cookie
3. 我打开了一些不相关的站点，浏览器创建了更多的渲染器和管道
4. 出于某种原因，我想在 facebook.com 浏览器中打开另一个标签，并且浏览器会向已经打开 facebook.com 的渲染器发送消息以渲染另一个标签。
5. 新选项卡包含第一个 facebook.com 选项卡可用的所有信息，因为它们正在共享一个进程（我会让该进程存储它自己的 cookie 副本或用于读取的内容，这样我就不必打扰数据库线程，但是可能不是 Chrome 的做法）。
6. 如果我决定退出数据库线程，则会看到 cookie 已更改并将其写入数据库。如果我保持登录状态，它不会触及数据库。

现在，我必须在此处添加默认 cookie 生命周期是浏览器关闭时它过期。因此，为了支持打开和关闭浏览器，网站必须告诉它覆盖这个生命周期（许多网站都会这样做）。

好的，所以如果浏览器覆盖了它的 cookie 生命周期，那么它就会存储在数据库中（是的，在文件系统上），当你返回这个站点时会再次读取它。将其存储在那里不安全吗？不，如果您的计算机没有受到损害并且操作系统正常工作，则不会。

附带说明一下，操作系统已经在检测和阻止攻击方面取得了进展。

至于使用另一个浏览器，它们都为 cookie 存储做了类似的事情，如果它让你很困扰，请使用 Chrome 的隐身模式或查看此文档，其中指出：

如果您希望 Google Chrome 在您关闭所有浏览器窗口时自动删除 cookie，请在“内容设置”对话框中选中“仅在我退出浏览器之前保留本地数据”复选框。您还可以设置例外，以便在您关闭浏览器时删除特定站点的 cookie。