https 站点的 Cookies 泄露问题，以及如何应对

本文由 Coxxs 原创，转载请注明原文链接：https://dev.moe/838

这几天，看见有人提到部分 https 站点的 Cookies 可通过中间人攻击泄露。按正常理解 https 已经加密了大多数内容，为什么还会泄露呢？读完原文，发现是因为目标站点配置错误所造成的（Spoiler: Cookies 未添加 Secure 属性）。

反思自己运维的网站，发现我的某个生产站点，竟也存在该问题（= =##）。匆忙修复后，写下本文，谈谈攻击的原理、站长如何修复以及用户如何规避。

怎么做到的？

原文提到的主要流程是中间人（如公共 Wi-Fi、ISP 等）劫持一个用户访问的任意 http 站点，插入脚本使用户发起针对目标 https 站点的 http 请求，然后截取此请求。

如果目标 https 站点的 Cookies 未添加 Secure 属性，对于 http 请求，浏览器也会发送用户此前留下的 Cookies。由于 http 是明文的，中间人便可截取此请求获得 Cookies。需要注意的是，此攻击并不受同源策略的限制。

测试下来，对于某些配置错误的站点确实可行（如X度贴吧等知名站点），且影响较大——获取 Cookies 后，中间人可进入用户账号，进一步获取隐私信息（如X度网盘中的文件与教育视频）。

站长如何修复？

最可靠的修复方案是：为 Cookies 添加 Secure 属性。

部署 HSTS Preload 且 includeSubDomains 也可以部分抵御此攻击，但如果遇上用户浏览器没更新 Preload 列表，而且 HSTS 正好还过期了，用户依然会暴露在风险之中。

当然，造成问题的根源在于开发者/运维人员（包括我 QAQ）的安全知识有缺失，认为支持 https 就一定安全了。建议多阅读 OWASP，否则即使这次修复了此问题，未来也可能会出现其他疏忽。

用户如何规避？

作为用户，一个个提醒有问题的站点添加 Cookies 的 Secure 属性显然不切实际，有别的方法规避这样的攻击吗？

不靠谱的方法

有人提到可以使用安全的 VPN，但这仅仅是将中间人攻击可能出现的位置从用户与目标站点间换到了 VPN 服务器与目标站点间，并不能彻底解决此问题。

还有人提到可以阻止 Third-party Cookies，但这也不能阻止中间人直接给你重定向到目标站点来发起 http 请求。

用户也可以选择屏蔽所有的 http 站点，这样攻击者的脚本就无处可插，但也会造成部分网站无法访问。此外，如果攻击者就是公共 Wi-Fi，用户还是得启用 http 才能登录 Wi-Fi，攻击者正好可以乘虚而入。

“HSTS” Everywhere!

一个可行的思路是，我们为每一个站点都启用 HSTS。这样即使用户请求了攻击者插入的 http 链接，浏览器也会自动将此请求在发起前升级为 https。而对于用户想访问的 http-only 站点（这样的站点现在已经不多了），用户可以手动为他们禁用 HSTS。这样真正做到了每一个支持 https 的站点，即使配置错误，也可以免于中间人攻击。

听起来很复杂，事实上一个浏览器插件就可以做到这一切。电子前哨基金会（EFF）的 HTTPS Everywhere 所提供的 https-only 模式正符合我们的需求。

更棒的是，就在前几天，此插件加入了一键添加 http 白名单的功能。如果遇到需要访问的 http-only 站点，在权衡风险后，用户可以快速为特定站点添加白名单以继续访问。

当然，如果上面的方法有什么缺陷，或是还有更多方法，也欢迎在评论中提出。

最后的一点思考..

https 网页中的 http 图片，就足以让浏览器感受到连接不安全，从而消除 UI 上的锁头标志。但重要 Cookies 未加 Secure 标识的危害显然远大于几张可能被篡改的图片。浏览器是否可以做些什么，向用户与站长提示这样的风险呢？

Coxxs