有 新闻与讨论 关于Gmail近期一个漏洞，该漏洞可能将您的联系人列表暴露给任意页面。
摘要： 如果您登录了Google账户（邮箱、个人主页等），其他网站可以利用该身份验证访问您的联系人列表。在访问半信任网站前请退出登录。
这是一个 跨站请求伪造 – 每天你都能学到新东西。有一个 详细文章见此处 关于Gmail漏洞的。
更新（1/1/07）： 该漏洞似乎已被修复。
工作原理
这个 代码 相当直接。基本上，Google文档有一个脚本会运行回调函数，将您的联系人列表作为对象传递给它。该脚本大概会检查cookie以确保您已登录Google账户，然后才交出列表。
不幸的是，它不检查是什么 页面 正在发起请求。所以，如果您在窗口1登录，窗口2（恶意网站）可以调用该函数并将联系人列表作为对象获取。由于您在别处登录，您的cookie是有效的，请求会通过。
此外，如果您检查返回的对象，会看到联系人的姓名、邮箱和“亲密度”(affinity)字段。通常，较高的亲密度意味着更常发送邮件的联系人，因此可能得知您联系人的相对重要程度。
可能的解决方案
Google由聪明人运营，我相信他们会很快修复。一些建议似乎正在涌现，都集中在确保用户位于Google.com页面而非随机网站上：
来源(Referrer)拦截：拦截所有来自非google.com域名的请求。然而，有些人使用来源拦截软件。这可能是他们为安全付出的代价，但可能还有其他后果。
脚本检查：我想到的一个方法是检查window.location（就像检查cookie一样）以确保请求来自google.com域名。这是查看发起请求页面的另一种方式。
挑战-响应(Challenge-response)：Google页面（如Gmail）可以有一些令牌(token)或唯一的计算数据随请求一起提交。随机页面在调用函数时无法访问此令牌。上述方案有效，但需要添加到每个表单字段，可能很繁琐。
（来自用户 JRF 在reddit上）：在请求中包含部分cookie URL 作为只有“真实”Google页面才知道的唯一令牌。需要注意代理/浏览器历史（其他页面可访问）可能获取此唯一数据。可能需要在挑战-响应系统中进行种子(seed)或加盐(salt)。这称为“双重提交”(double-submitting) cookie——服务器可以检查您的cookie是否确实包含您提交的值（恶意页面无法直接访问您的cookie，只知道您已登录）。
思考这个问题的解决方案很有趣——您还有其他想法吗？
我相信Google会修复这个问题，但在网络上浏览随机网站时要小心（显然，但请特别警惕）。先退出Google登录。
这是对网络安全现实的一记警钟。
其他资源
- CSRF 解释与 PHP 代码](http://shiflett.org/articles/cross-site-request-forgeries) – 包含使用令牌认证的示例 PHP。