假设我通过 opendID 连接提供程序登录并被重定向到我的回调 www.mysite.com/auth/callback。然后，我创建了一个 httponly cookie，其中包含一个引用我收到的令牌的 id，该 cookie 在wwww.mysite.com/ 处传递给浏览器。另一个站点如何提交包含相同会话 cookie 的请求？浏览器是否仅传递请求域的 cookie。那么如果www.evil.com尝试向www.mysite.com/api/endpoint发起请求，会不会session cookie不通过，使得伪造的请求无效？
我在这里缺少一些基本的东西吗？？
【问题讨论】：
当网络浏览器向不同的域发送请求时，它们会先检查是否已经有该域的 cookie，如果有，然后将它们与请求一起发送。因此，如果您正在使用 Web 应用程序尝试向您的应用程序发送请求，它会将该请求与您的 cookie 一起发送。防伪令牌背后的想法是，即使 Web 浏览器发送了所有这些信息，如果令牌与您根据应用程序提交的合法请求创建的令牌不匹配，它也会失败。
如果您不希望通过跨站点请求发送您的 cookie，您可以为您的 cookie 使用 samesite 标志。在这里，您可以在 Strict 和 Lax 模式之间做出决定。在严格模式下，您永远不会通过跨站点请求发送您的站点 cookie，因此您不需要关心会话 cookie 是否被发送。这里的问题是，如果您从不同的站点重定向，例如，如果您在这里，并尝试转到 facebook（如果 facebook 使用严格模式），您的 cookie 将不会被发送，您需要再次进行身份验证（这可能是一个烦人的功能，也可能是一个很好的功能，具体取决于您的应用程序和您的用户群）。
Lax 模式非常相似，但在这种模式下，您只能通过安全的 HTTP 动词（GET、HEAD、OPTIONS 和 TRACE）发送 cookie，因此您仍然可以获得针对 POST/PUT XSRF 攻击的保护，但您不需要GET 请求不会有烦人的行为。由您决定哪一个更适合您的应用。
有关 XSRF 和同站点 cookie 的更多信息：http://arnoldcer.com/2017/03/14/cross-site-request-forgery-what-it-is-how-to-exploit-it-and-how-to-defend-against-it/
【讨论】：
evil.com，它将使用它作为请求域，而不管该页面上发出了什么请求。这是不正确的。浏览器将根据相应请求的域添加 cookie。 samesite 标志是对 csrf 令牌需求的有趣替代方案。