事发原因首先介绍一下基本情况：公司某业务系统是h.xxx.com，通过网页护照登录。xxx.com嵌入到iframe中。在本地开发环境中，业务系统只支持http协议，所以对应的访问地址为http://h.xxx.com，登录界面始终为https://passport.xxx.com。这是一种跨协议的情况。问题某天，有同学登录系统后，一直说“您没有登录，请先登录B站”，并不是每个人都有这个问题。经过一系列排查，发现唯一的区别就是Chrome浏览器版本不一致（使用其他一些浏览器是没有问题的）。从v88升级到v89后，chrome浏览器内置的schemeful-same-site规则默认值改为enable，导致跨协议被识别为跨站，无法传递cookie.临时解决方案：在地址栏中打开chrome://flags/#schemeful-same-site并将选项设置为Disabled。在Chrome80中，SameSite的默认值更改为Lax。如果eTLD+1的一部分是一致的，那么Same-Site的概念就可以称为same-site。如果scheme与eTLD+1部分一致，则称为schemefulsame-site。下面是一些诡计多端的同站示例：OriginAOriginB诡计多端的同站https://www.example.com:443https://www.evil.com:443cross-site:不同的域名https://login.example.com:443schemeful同站：允许不同子域名http://www.example.com:443cross-site：不同协议https://www.example.com:80schemeful同站：允许不同端口https://www.example.com:443schemefulsame-site:完全匹配https://www.example.comschemefulsame-site:允许不同端口协议+域名的维度。如果你想了解更多，可以浏览这篇文章：Understanding'same-site'and'same-origin'。这意味着http://website.example和https://website.example彼此是跨站点的。如果你的网站已经使用了HTTPS，那么SchemefulSame-Site不会有任何影响，否则你应该尽快升级到HTTPS。如果你的项目同时使用了HTTP和HTTPS，那么了解相关规则是很有必要的。接下来介绍一些场景和对应的??cookie行为。过去，可以通过设置SameSite=None来允许跨协议的cookie传输；安全的。原作者建议不要使用这个临时方案。应尽快在整个站点部署HTTPS。其实也确实是这样，就像之前的登录问题一样，你永远不知道浏览器下一次抛给你的“惊喜”是什么。浏览器相关设置Chrome和Firefox提供了schemeful-same-site配置入口。从Chrome86开始，将chrome://flags/#schemeful-same-site选项修改为Enabled以启用它。从Firefox79开始，打开about:config并将network.cookie.sameSite.schemeful选项修改为true。在以前的浏览器更新中，SameSite=Lax已设置为默认值，以防止跨站点请求伪造(CSRF)攻击。但是，攻击者仍然可以通过不安全的HTTP协议篡改cookie，从而影响也使用相同cookie的HTTPS页面。schemuled-same-site应运而生。常见的跨协议场景导航跳转前两次跨协议和同域名页面跳转允许携带cookie设置为SameSite=Strict。不同的协议现在被认为是跨站点的，因此设置为SameSite=Strict的cookie会被阻止。HTTP→HTTPSHTTPS→HTTPSameSite=Strict?Blocked?BlockedSameSite=Lax?Allowed?AllowedSameSite=None;Secure?Allowed?Blocked加载子资源主流浏览器会屏蔽activemixedcontent（活动混合内容），比如scripts和iframe。Chrome和Firefox浏览器正在尝试升级或阻止被动混合内容（passivemixedcontent）。Subresources（子资源）包括图像、iframe和XHR，如果页面在Fetch请求之前加载跨协议资源，它们可以共享设置为SameSite=Strict和SameSite=Lax的cookie。不过现在两者都被浏览器屏蔽了，无法传输和分享。另外，即使HTTPS可以加载HTTP资源，所有的cookie仍然会被屏蔽。HTTP→HTTPSHTPS→HTTPSameSite=Strict?Blocked?BlockedSameSite=Lax?Blocked?BlockedSameSite=None;Secure?Allowed?BlockedPOST表单提交以前的跨协议POST请求可以携带设置为SameSite=Lax或SameSite=Strict的cookie。现在只有设置了SameSite=None的cookie才会在表单请求中发送。HTTP→HTTPSHTTPS→HTTPSameSite=Strict?Blocked?BlockedSameSite=Lax?Blocked?BlockedSameSite=None;Secure?Allowed?Blocked如何在网页上测试Chrome和Firefox上的开发者工具已经支持相关配置，并且会给出Prompt。从Chrome版本86开始，DevTools->Issue显示有关SchemefulSame-Site的高亮提示。导航问题：“完全迁移到HTTPS以继续在同一站点请求上发送cookie”——警告cookie将在未来版本的Chrome中被阻止。“完全迁移到HTTPS以在同一站点请求上发送cookie”—cookie已被阻止的警告。子资源加载问题：“完全迁移到HTTPS以继续将cookie发送到同站点子资源”或“完全迁移到HTTPS以继续允许由同站点子资源设置cookie”—cookie将在未来版本的Chrome中被阻止的警告。“完全迁移到HTTPS以将cookie发送到同一站点子资源”或“完全迁移到HTTPS以允许通过同一站点子资源设置cookie”—警告cookie已被阻止。后一个警告也可以在POSTing表单时出现。详情可以阅读TestingandDebuggingTipsforSchemefulSame-Site。从Firefox79版本开始，network.cookie.sameSite.schemeful设置为true后，控制台也会显示相关信息：“Cookiecookie_namewillbesoonbetreatedascross-sitecookieagainsthttp://site.example/因为方案不匹配。”“Cookiecookie_name已被视为针对http://site.example/的跨站点，因为方案不匹配。”常见问题我的网页已经使用HTTPS，为什么我仍然看到问题？网页中的某些链接或资源可能仍指向不安全的地址。一种解决方案是使用HTTP严格传输安全(HSTS)+includeSubDomain。使用HSTS+includeSubDomain方案后，即使你的页面中存在不安全链接，浏览器也会自动替换安全协议访问。如果我无法升级到HTTPS，我可以调整SameSite的设置并放宽限制。只有当SameSite=Strictcookies被屏蔽时，可以调整为SameSite=Lax设置为Strict或Laxcookies被屏蔽，cookies被发送到一个安全的URL，设置为None后才会生效。如果cookie没有设置SameSite属性怎么办？没有SameSite属性的Cookie将被视为SameSite=Lax。WebSocketsSame-site:wss://连接来自https://ws://连接来自http://Cross-site:wss://连接来自http://ws://连接来自https://这篇文章主要内容来自：诡计多端的同站关注公众号：湖中剑来了解更多关于我的信息。
