chrome 同站策略（samesite）问题及解决方案

chrome 同站策略（samesite）问题及解决方案

一、同站策略问题

chrome自版本80之后，出现了所谓同站策略问题。

即，在A页面请求B页面，如果chrome发现它们不是同一个站点的话，就不传cookie给B页面所在的服务器。众所周知，原本cookie是会附在浏览器到服务器的每个请求（request）里的，仿佛这是理所应当，自然而然的，现在好了，chrome区分情况，不一定允许这么干了。

这样的后果是什么呢？就是有些功能以前没问题的，现在不行了。拿我们项目来说，原本我们有些WEB项目，会用iframe将其他项目的一些页面嵌进去，看上去就好像同一个系统一样，这叫界面集成吧，很正常的行为。两边项目的自动登录什么的都搞好了，一直运行正常。后来升级了浏览器，发现嵌进去的页面数据出不来。程序没有做任何更改，最后发现是账号登录问题，嵌进去的页面始终处于无法登录状态，从而导致获取不了数据。

具体来说，cookie是由服务器分配给浏览器的，相当于给了浏览器一个访问凭证。浏览器每次访问服务器的时候，都会带上这些个凭证。现在由于浏览器策略改变，嵌进去的页面与服务器交互的时候，无法带上cookie，服务器检索不到这个凭证，就每次都给页面分配一个新的cookie，前后对应不上，当然就登录不了了。

其实，chrome一直有这个同站策略，Chrome 51 开始，浏览器的 Cookie 新增加了一个SameSite属性，用来防止 ​​CSRF 攻击​​和用户追踪。SameSite可以设置三个值：

Strict Lax None

Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。

Lax规则稍稍放宽，分情况处理，具体如下

None的话，就不做是否同站的检查和限制。以前，chrome默认SameSite=None，80版本以后则默认是Lax了。这也是为什么chrome升级以后，程序突然异常的缘故。

二、解决方案

1、修改浏览器设置 这种方法简单粗暴，直接将浏览器的SameSite的属性设置回到以前的None状态。姑且不论用户是否愿意，但单就每台机的浏览器都要进行设置而言，已经违背了BS架构应用的最大优点，就是客户端无须安装部署这一宗旨。所以我觉得这是一个实在没有别的办法的时候，才不得不采取的措施。

设置方法如下：

1）chrome地址栏输入chrome://flags 2）通过禁用“SameSite by default cookies”和“Cookies without SameSite must be secure”功能开关 3）重新启动浏览器

2、Set-Cookie：SameSite=None 就是将response的header设置Set-Cookie：SameSite=None。

Set-Cookie: SameSite=None;

​​Set-Cookie​​

这里有个疑问，谁来设置这个set-cookie?以上述我们项目为例，A项目的页面用iframe嵌入了B项目的页面，是A项目来设置set-cookie还是B项目？应当是B。因为嵌入的是B项目的页面，response来自B服务器，A使不上劲。

注意必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。这意味着，B项目必须采用SameSite 为 none的实例。以 Adobe 网站为例： 1;error_log logs/error.log debug;events { worker_connections 1024;}{ server { listen 8082; server_name localhost; location / { proxy_pass } }}

2）运行nginx

nginx.exe -c D:\soft\nginx-rtmp-win32-1.2.1\conf\nginx2.conf

映射之后，A项目嵌入的B项目页面改用新地址，浏览器就以为它们是同一站点，放松警惕，该干啥干啥了。

三、总结

谷歌浏览器的这种同站策略是一种傲慢，虽然它也允许B服务器设置SameSite=None，但要跟采用的 SameSite 属性​​​​浏览器系列之 Cookie 和 SameSite 属性​​

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。