SameSite 设置可使开发人员限制对cookie的访问。例如，通过设置 SameSite=strict，当用户通过其它网站发出的链接或重定向请求导航到该网站时，它可阻止cookie 出现在 HTTP 响应中。

安全研究员 Axel Chong 发现，如果使用intent scheme 导航到目标网站，则可绕过SameSite 防护措施。Intents是一种外部协议句柄，允许安卓应用打开其它应用，如从浏览器跳转到 Maps 应用或者从SMS跳转到浏览器。

他提到，“我在读到关于intents上的有趣bug (Issue 1249962) 时，发现了这个bug。因为intent URL 可指向同样的app（本案例中是Chrome）并创建一个新的浏览上下文，因此我后来在思考intent URL 很可能绕过哪种安全措施。”

Intent URL 可被视作外部来源并受SameSite 限制。但Chong 用Python 创建的PoC 显示，当web服务器通过intent URL 启动重定向时，设置了 SameSite=strict 的cookie 会遗留下来。

该scheme 还会绕过 Sec-Fetch-Site 标头，判断请求源自何处并可使网站从外部来源控制对资源的访问权限。Chong 表示，“两者都用于防御CSRF攻击，因此造成的影响就是绕过这些防护措施。”

进一步调查发现，在没有 intent 协议的情况下，SameSite cookie也会通过简单的重定向请求而遗留下来。

虽然该问题已在 Chrome 的一个早期版本中修复，但由于它会破坏变更，因此随后被禁用。

该试验性 cookie 特性标记 (chrome://flags/#enable-experimental-cookie-features) 将恢复安全行为并阻止在普通的请求中发送SameSite cookie。该标记并不会影响intent 重定向的不安全行为。Chong 还提到该标记并不影响 Sec-Fetch-Site 行为，后者应该单独修复。

修复该漏洞并不简单，因为开发人员必须为包括浏览器在内的可信应用的判断担责。

最终的修复方案决定不信任intents，理由有二。一是，设备上的其它应用可能不值得信任；二是网站可使用Intent URL/重定向反射到Chrome 并可能借此绕过SameSite 的限制。”

该漏洞告诉我们，鉴于应用和浏览器通信可达到的复杂性，开发人员应当在应用上使用多个安全层。Chong 建议，“这种浏览器安全机制（如SameSite cookie、Fetch 元数据）的目的是仅仅实现纵深防御。你应该使用它们但不应将它们作为唯一的防御方式。”

题图：Pexels License

本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。

    觉得不错，就点个 “在看” 或 "赞” 吧~