【web技术】有Schema的相同站点

“同一站点”的定义正在演变为包括URL方案，因此站点的HTTP和HTTPS版本之间的链接现在被视为跨站点请求。默认情况下升级到HTTPS以尽可能避免出现问题，或者继续阅读以了解需要哪些SameSite属性值的详细信息。

注意：本文是SameSite cookie属性更改系列文章的一部分，其中包括：

• 了解Cookie
• SameSite cookie解释
• SameSite饼干配方

Schemeful Same Site(Schemeful Same-Site)将（网站）的定义从仅可注册域修改为scheme+可注册域。您可以在理解“相同站点”和“相同来源”中找到更多详细信息和示例。

关键术语：这意味着不安全的HTTP版本的网站，例如，http://website.example，以及该站点的安全HTTPS版本，https://website.example，现在被认为是跨站点的。
好消息是：如果你的网站已经完全升级到HTTPS，那么你不需要担心任何事情。对你来说什么都不会改变。

如果你还没有完全升级你的网站，那么这应该是优先事项。但是，如果您的网站访问者在HTTP和HTTPS之间进行访问，那么下面概述了一些常见的场景和相关的SameSite cookie行为。

警告：长期计划是完全取消对第三方cookie的支持，代之以保护隐私的替代品。设置SameSite=无；在向完全HTTPS迁移的过程中，对cookie进行安全保护以允许其跨方案发送只应被视为一种临时解决方案。

您可以启用这些更改以在Chrome和Firefox中进行测试。

• 从Chrome 86，启用about://flags/#schemeful-same-site。在Chrome状态页面上跟踪进度。
• 在Firefox 79中，通过about:config将network.cookie.sameSite.schemeful设置为true。通过Bugzilla问题跟踪进度。

更改为SameSite=Lax作为cookie默认设置的主要原因之一是为了防止跨站点请求伪造（CSRF）。然而，不安全的HTTP流量仍然为网络攻击者提供了篡改cookie的机会，这些cookie将在网站的安全HTTPS版本上使用。在方案之间创建这种额外的跨站点边界提供了对这些攻击的进一步防御。

常见的跨方案场景

关键词：在下面的例子中，URL都有相同的可注册域，例如site.example，但不同的方案，例如，http://site.examplevs。https://site.example，它们相互称为交叉方案。

航行(Navigation)

在网站的跨方案版本之间导航（例如，从链接http://site.example到https://site.example)之前将允许发送SameSite=严格的cookie。这现在被视为跨站点导航，这意味着SameSite=Strict cookie将被阻止。

Cross-scheme navigation from HTTP to HTTPS.

HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Blocked	⛔ Blocked
SameSite=Lax	✓ Allowed	✓ Allowed
SameSite=None;Secure	✓ Allowed	⛔ Blocked

正在加载子资源

警告：所有主流浏览器都会阻止脚本或iframe等活动的混合内容。此外，包括Chrome和Firefox在内的浏览器正在努力升级或阻止被动混合内容。

您在此处所做的任何更改只应被视为在升级到完全HTTPS时的临时修复。

子资源的示例包括图像、iframe和使用XHR或Fetch进行的网络请求。

在页面上加载跨方案子资源之前会允许发送或设置SameSite=Strict或SameSite=Lax cookie。现在，这与任何其他第三方或跨站点子资源的处理方式相同，这意味着任何SameSite=Strict或SameSite=Lax cookie都将被阻止。

此外，即使浏览器允许将来自不安全方案的资源加载到安全页面上，由于第三方或跨站点cookie需要安全，因此这些请求中的所有cookie都将被阻止。

An HTTP page including a cross-scheme subresource via HTTPS.

HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Blocked	⛔ Blocked
SameSite=Lax	⛔ Blocked	⛔ Blocked
SameSite=None;Secure	✓ Allowed	⛔ Blocked

POSTing a form

在网站的跨方案版本之间发布之前，将允许发送设置为SameSite=Lax或SameSite=Strict的cookie。现在，这被视为跨站点POST——只能发送SameSite=None cookie。您可能会在默认情况下提供不安全版本的网站上遇到这种情况，但在提交登录或签出表单时将用户升级到安全版本。

与子资源一样，如果请求从安全的（如HTTPS）上下文转到不安全的（例如HTTP）上下文，则由于第三方或跨站点cookie需要安全，因此这些请求上的所有cookie都将被阻止。

警告：这里的最佳解决方案是确保表单页面和目标都处于HTTPS等安全连接上。如果用户在表单中输入任何敏感信息，这一点尤为重要。

HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Blocked	⛔ Blocked
SameSite=Lax	⛔ Blocked	⛔ Blocked
SameSite=None;Secure	✓ Allowed	⛔ Blocked

如何测试我的网站？

Chrome和Firefox提供了开发人员工具和消息传递功能。

在Chrome 86中，DevTools中的Issue选项卡将包括Schemeful Same Site问题。您可能会看到您的网站突出显示了以下问题。

导航问题：

• “完全迁移到HTTPS以继续在同一网站请求上发送cookie”——警告cookie将在未来版本的Chrome中被阻止。
• “完全迁移到HTTPS以在同一站点请求上发送cookie”--cookie已被阻止的警告。

子资源加载问题：

• “完全迁移到HTTPS以继续将cookie发送到同一站点子资源”或“完全迁移至HTTPS以继续允许cookie由同一站点的子资源设置”--警告cookie将在未来版本的Chrome中被阻止。
• “完全迁移到HTTPS以将cookie发送到同一站点子资源”或“完全迁移至HTTPS以允许cookie由同一站点的子资源设置”--cookie已被阻止的警告。张贴表单时也可能出现后一个警告。

更多详细信息，请参阅Schemeful Same Site的测试和调试提示。

从Firefox 79，通过about:config将network.cookie.sameSite.schemful设置为true，控制台将显示关于schemeful Same Site问题的消息。您可以在您的网站上看到以下内容：

• “Cookie Cookie_name将很快被视为跨站点Cookiehttp://site.example/因为该方案不匹配。"
• “Cookie Cookie_name已被视为跨站点攻击http://site.example/因为该方案不匹配。"

常见问题

我的网站已经在HTTPS上完全可用，为什么我在浏览器的DevTools中看到问题？

您的一些链接和子资源可能仍然指向不安全的URL。

解决此问题的一种方法是使用HTTP严格传输安全性（HSTS）和includeSubDomain指令。使用HSTS+includeSubDomain，即使您的某个页面意外包含不安全的链接，浏览器也会自动使用安全版本。

如果我不能升级到HTTPS怎么办？

虽然我们强烈建议您将网站完全升级为HTTPS以保护用户，但如果您自己无法升级，我们建议与您的托管提供商联系，看看他们是否可以提供该选项。如果您是自托管的，那么Let's Encrypt提供了许多工具来安装和配置证书。您还可以调查将您的网站移动到CDN或其他可以提供HTTPS连接的代理之后。

如果仍然无法做到这一点，请尝试放松受影响cookie的SameSite保护。

• 在只有SameSite=Strict cookie被阻止的情况下，您可以将保护降低到Lax。
• 如果Strict和Lax cookie都被阻止，并且您的cookie被发送到（或从）安全URL，您可以将保护降低到None。
  • 如果您将cookie发送到（或从中设置cookie）的URL不安全，则此解决方法将失败。这是因为SameSite=None需要cookie上的Secure属性，这意味着这些cookie可能不会通过不安全的连接发送或设置。在这种情况下，在您的网站升级到HTTPS之前，您将无法访问该cookie。
  • 请记住，这只是暂时的，因为最终第三方cookie将被完全淘汰。

如果我没有指定SameSite属性，这会对我的cookie产生什么影响？

没有SameSite属性的Cookie将被视为指定了SameSite=Lax，同样的跨方案行为也适用于这些Cookie。请注意，不安全方法的临时例外仍然适用，有关更多信息，请参阅Chromium SameSite常见问题解答中的Lax+POST缓解。

WebSockets是如何受到影响的？

如果WebSocket连接与页面具有相同的安全性，则它们仍将被视为相同的站点。

同一站点：

• wss:// connection from https://
• ws:// connection from http://

跨站点：

• wss:// connection from http://
• ws:// connection from https://