由于浏览器会阻止访问其他站点的 cookie，因此单独使用访问令牌是否可以防止 CSRF 攻击？
我是网络安全新手，当我了解 CSRF 时，我有一个非常简单的问题：
假设我们有这样的场景：
在网络浏览器上，我访问一个普通网站（称为网站 A）并使用凭据登录。
我通过身份验证后，网站 A 会发出一个访问令牌供我的浏览器存储。当我使用网站 A 时，我发出的任何后续 http 请求都会发送到 api 端点，并且身份验证令牌会附加到请求中。
现在我访问了一个邪恶的网站。当恶意网站的 html / javascript 前端代码在浏览器中加载时，它会诱使我向网站 A 的 api 端点发出 HTTP 请求。
但是，由于不同来源的资源（DOM、本地存储、cookie）被隔离在在浏览器中，邪恶站点的前端代码无法访问网站 A 的访问令牌。因此，向网站 A 的 api 端点发起的 HTTP 请求将不包含访问令牌。请求不会成功。
在我看来，单独使用身份验证令牌就可以防止 CSRF，只要不同来源的 cookie 被隔离并且无法跨源访问，这在现代网络浏览器中是相当明确的。
一个网站的前端代码绝对不可能在浏览器中获取另一个网站的 cookie/DOM/存储。
为什么有那么多其他的技术来防止 CSRF？
I am new to web security and as I am learn about CSRF, I have a very simple question:
Say we have this scenario:
On web browser, I visit a normal website (call it website A) and login with credentials.
After I am authenticated, website A would issue an access token for my browser to store. As I am using website A, any subsequent http requests I make are sent to the api endpoints and the auth token is attached with the requests.
Now I visit an evil website. When the html / javascript frontend code of the evil website loads in the browser, it induces me to issue an HTTP request to the api endpoint of website A.
However, since resources (DOM, local storage, cookies) of different origins are segregated in the browser, there is no way for the evil site's frontend code to access the access token of website A. Therefore the induced HTTP request to api endpoint of website A would contain no access token. The request would not be successful.
It seems to me that using authentication token alone can prevent CSRF, as long as cookies of different origins are segregated and not accessible cross-origin-wise, which is pretty definite in modern day web browser.
There is absolutely no way that one website's frontend code can get another site's cookies / DOM / storage in browser.
Why are there all those other techniques of preventing CSRF?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
问题是cookie。如果令牌存储在 cookie 中，它将与请求一起发送给受害者，无论请求是从哪里发送的。这意味着即使发送请求的站点是attacker.com，令牌cookie也会发送到victim.com。
现在有一个新的 cookie 属性
SameSite可以防止这种情况发生，其目的就是缓解 CSRF，而且还有更传统的方法来确保请求是在合法的应用程序源上发出的（例如同步器令牌、双重提交等）。另请注意，如果令牌不是作为 cookie 发送（而是在请求标头或仅在请求正文中），则通常不需要进一步的保护。不过，可能存在特殊的边缘情况，其他形式的身份验证会自动发送凭据，例如 http 基本身份验证或客户端证书，但这些身份验证很少在正常的 Web 应用程序中用于人类交互。
The problem is cookies. If the token is stored in a cookie, it will be sent with requests to the victim, regardless of where the request is being sent from. This means that the token cookie will be sent to victim.com even if the site sending the request is attacker.com.
There is now a new-ish cookie attribute
SameSitethat prevents this with the very purpose of mitigating CSRF, and also there are the more traditional approaches to make sure a request was made on the legitimate app origin (like synchronizer tokens, double submit and so on).Also note that if the token is not sent as a cookie (but in something like a request header, or just in the request body), no further protection is needed in general. There may be special edge cases though, other forms of authentication that do send credentials automatically, like for example http basic auth or client certificates, but those are rarely used in a normal web app for humans to interact with.