Security 为什么在使用会话cookie时需要csrf令牌？

假设我通过opendID连接提供商登录，并被重定向到我的回调

www.mysite.com/auth/callback

。然后，我创建一个httponly cookie，其中包含一个引用我收到的令牌的id，该id被传递到

wwww.mysite.com/

上的浏览器。另一个站点如何提交包含相同会话cookie的请求？浏览器是否仅传递请求域的Cookie。因此，如果

www.evil.com

试图向

www.mysite.com/api/endpoint

发出请求，会话cookie不会被传递，从而使伪造的请求无效吗

---

我是否遗漏了一些基本信息？？？

当web浏览器向其他域发送请求时，他们会首先检查是否已经为该域提供了cookie，如果已经提供了cookie，则会将其与请求一起发送。因此，如果您在web应用程序上尝试向您的应用程序发送请求，它会将该请求与您的cookie一起发送。防伪令牌背后的思想是，即使web浏览器发送所有这些信息，如果令牌与您在应用程序提交的合法请求中创建的令牌不匹配，它也会失败

如果您不希望通过跨站点请求发送cookie，您可以对cookie使用

samesite

标志。在这里，您可以在严格模式和宽松模式之间进行选择。在严格模式下，您永远不会通过跨站点请求发送站点cookie，因此您不需要关心会话cookie的发送。这里的问题是，如果您从不同的站点重定向，例如，如果您在这里，并尝试转到facebook（如果facebook使用严格模式），您的cookie将不会被发送，您将需要再次验证（这可能是一个恼人的或好的功能，取决于您的应用程序和用户群）。 Lax模式非常类似，但在这种模式下，您只能通过安全的HTTP动词（GET、HEAD、OPTIONS和TRACE）发送cookie，因此您仍然可以获得针对POST/PUT XSRF攻击的保护，并且GET请求不会出现令人讨厌的行为。这取决于你决定哪一个将是你的应用程序更好的选择

---

关于XSRF和samesite Cookie的更多信息：

我设想，如果浏览器位于url

evil.com

，它将使用它作为请求域，而不管在该页面上发出了什么请求。这是不正确的。浏览器将根据相应请求的域添加cookie。samesite标志是csrf令牌需求的一个有趣的替代方案。