最近在公司研发群,发现有人反馈内部网站跨域访问莫明的出现站点重定向问题,而且都是谷歌80 版本以后出现。 javascript
重定向的缘由无非就是没有cookie,致使没有登陆态。沿着这个思路咱们展开了一系列的探索。java
结果:失败,没有解决问题 git
结果:成功解决,可是,这个方案有点局限,若是全部人都遇到这个问题,你还须要给每个人都去说一遍,你须要打开chrome://flags/ ,设置SameSite,天,太麻烦了。出口堵住太麻烦了,固然这也是一种临时方案,因此咱们仍是要像一个简单点的方案,就是历来源去解决。 github
网站跨域访问莫明的出现站点重定向,源头在哪,就是在统一登陆的地方,若是咱们在统一登陆的地方设置了SameSite,哪是否是就在全部用到当前登陆态的地方就解决了这个问题。怎么操做了。 操做很简单,其实就是在报文里面set-cookie,添加SameSite=None; Secure chrome
结果:完美解决,一劳永逸。不要给全部人解释你须要怎么怎么作了。 api
最后我回过来思考一下为何会出现这样的缘由了。你们发如今探索的过程当中,基本都是改变了SameSite的设置,才成功解决的。 Cookie 的SameSite属性用来限制第三方 Cookie,从而减小安全风险。它能够设置三个值:跨域
Strict最为严格,彻底禁止第三方 Cookie,跨站点时,任何状况下都不会发送 Cookie。换言之,只有当前网页的 URL 与请求目标一致,才会带上 Cookie。浏览器
Set-Cookie: CookieName=CookieValue; SameSite=Strict;
复制代码
这个规则过于严格,可能形成很是很差的用户体验。好比,当前网页有一个 GitHub 连接,用户点击跳转就不会带有 GitHub 的 Cookie,跳转过去老是未登录状态。安全
Lax规则稍稍放宽,大多数状况也是不发送第三方 Cookie,可是导航到目标网址的 Get 请求除外。bash
Set-Cookie: CookieName=CookieValue; SameSite=Lax;
复制代码
设置了Strict或Lax之后,基本就杜绝了 CSRF 攻击。固然,前提是用户浏览器支持 SameSite 属性。
网站能够选择显式关闭SameSite属性,将其设为None。不过,前提是必须同时设置Secure属性(Cookie 只能经过 HTTPS 协议发送),不然无效。
Set-Cookie: widget_session=abc123; SameSite=None; Secure
复制代码
chrome升级到80版本以后(准确的说是78版本以后),cookie的SameSite属性默认值由None变为Lax,这个才是本次事件的根本缘由。
这个问题在社区也是有讨论的,讨论地址:github.com/google/goog…