首页 > 解决方案 > 响应中设置的 cookie 的 Samesite 属性没有被 tomcat 的 cookie 处理器修改

问题描述

最近浏览器正在通过将samesite cookie默认值增强为Lax来提高安全性以防止CSRF攻击,即如果服务器在通过response set-cookie header设置cookie时没有设置samesite属性,浏览器会将其视为Lax,而不是存储,因此在随后的调用中,cookie 不会发送回失败的服务器。这发生在跨域通信中,跨域应用程序在主网站的 iFrame 中运行。

我们有一个这样的服务器应用程序,它在成功的身份验证请求的响应中设置两个 cookie,并且这些 cookie 应该在每次后续调用时发送回服务器,以使服务器相信请求已经过身份验证以进行进一步处理。这些 cookie 没有明确设置任何相同站点属性,因此新浏览器 (Chrome 80) 不会在后续调用中将它们发送回。

服务器应用程序托管在 tomcat 上。所以为了缓解这个问题,我们使用 tomcat 的cookieprocessor将 cookie 的 samesite 属性设置为“none”,以便进行跨域调用。不幸的是,这并没有奏效。尽管通过 cookieprocessor 明确设置了 samesite 属性,但通过开发人员工具检查时的响应不会显示任何相同站点属性的痕迹。

所以这里的问题是:我是否正确地认为tomcat应该修改服务器的响应以将samesite属性添加到通过响应上的set-cookie标头设置的cookie中?我尝试通过设置远程调试来调试 cookieprocessor 代码,但看起来响应没有被拦截,因此 cookie 标头正在被修改。我在这里做错了什么?

注意:我已经在应用程序的 meta-inf/context.xml 中配置了 cookieprocessor。

标签: google-chrometomcatcookiessamesite

解决方案


所以您使用的是 Tomcat,但是您使用的是什么版本的 Tomcat?

CookieProcessor SameSite 支持的初始版本使用“无”来指代取消设置 SameSite 值的行为。

https://bz.apache.org/bugzilla/show_bug.cgi?id=63865

Fixed in:
- master for 9.0.28 onwards
- 8.5.x for 8.5.48 onwards

我不确定来自 Tomcat 的 CookieProcessor 是否考虑了客户端的用户代理。

如果您以这种方式实现,您的应用程序可能不支持已知的不兼容客户端:Chrome 51-66、MacOSX Mojave (10.14) Safari/Embedded、iOS 12、UCBrowser 12.13.2 之前的版本

https://www.chromium.org/updates/same-site/incompatible-clients

我们通过使用 addHeader 来支持 SameSite 解决了我们的普通 cookie。

我们在 nginx 层解决了会话 cookie。

对于 JSESSIONID,您似乎还可以使用过滤器来包装 HttpServletRequest,以便在创建新会话时附加具有适当属性的会话 cookie 的副本。虽然它为覆盖的 JSESSIONID 添加了大约 80B。


推荐阅读