最近浏览器正在通过将samesite cookie默认值增强为Lax来提高安全性以防止CSRF攻击，即如果在通过响应set-cookie header 设置cookie时服务器未设置samesite属性，浏览器将认为它们是Lax，并且不存储，因此在后续调用中，如果这些请求失败，cookie 不会发送回服务器。这发生在跨域通信中，跨域应用程序在主网站的 iFrame 中运行。
我们有一个这样的服务器应用程序，它在成功的身份验证请求的响应上设置两个 cookie，这些 cookie 应该在每次后续调用时发送回服务器，以使服务器相信请求已通过身份验证以进行进一步处理。这些 cookie 没有明确设置任何 samesite 属性，因此新浏览器 (Chrome 80) 不会在后续调用中将它们发回。
服务器应用程序托管在 tomcat 上。所以为了缓解这个问题，我们使用了 tomcat 的 cookieprocessor将cookie的samesite属性设置为“none”，这样就可以进行跨域调用了。不幸的是，这没有用。尽管通过 cookieprocessor 显式设置了 samesite 属性，但通过开发人员工具检查时的响应不会显示任何 samesite 属性的痕迹。
所以这里的问题是:tomcat 应该修改服务器的响应以将 samesite 属性添加到通过响应中的 set-cookie header 设置的 cookie，我是否理解正确？我尝试通过设置远程调试来调试 cookieprocessor 代码，但看起来响应没有被拦截，因此 cookie header 被修改了。我在这里做错了什么？
注意:我已经在应用程序的 meta-inf/context.xml 中配置了 cookieprocessor。
最佳答案
那么您正在使用 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、12.13.2 之前的 UCBrowser
https://www.chromium.org/updates/same-site/incompatible-clients
我们通过使用 addHeader 来支持 SameSite 来解决我们的正常 cookie。
我们在 nginx 层解决了我们的 session cookie。
对于 JSESSIONID，似乎您还可以使用过滤器来包装 HttpServletRequest，以便在创建新 session 时附加具有适当属性的 session cookie 的副本。尽管它为重写的 JSESSIONID 添加了大约 80B。
关于google-chrome - tomcat cookieprocessor 未修改响应中设置的 cookie 的 Samesite 属性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/60214654/