CSRF 可以在没有 Cookie 的情况下实现吗？
我对此进行了一段时间的研究，但没有找到任何东西可以满足我的好奇心。如果禁用 cookie，作为用户是否有可能成为 CSRF 攻击的受害者。显然，CSRF 依赖于用户浏览器将用户的凭据和伪造的请求发送到合法服务器。除了 IP 地址之外，浏览器不会自动发送任何其他会话值，不是吗？在这种情况下，只要用户可以在禁用 cookie 的情况下登录，即使在易受攻击的网站上，他们也能免受 CSRF 的攻击。
I have been investigating this for some time, but I haven't found anything to satisfy my curiosity. Is it possible, as a user, to be the victim of a CSRF attack if cookies are disabled. Obviously CSRF depends on the users browser to send the user's credentials with the forged request to the legitimate server. Besides IP addresses, browsers don't automatically send in any other session values do they? In that case, as long as a user can login with cookies disabled, they would be safe from CSRF even on vulnerable websites.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
浏览器还支持其他形式的身份验证，特别是 HTTP Basic 和 HTTP Digest，以及 SSL/TLS 客户端证书。不幸的是，使用这些机制时“注销”的界面通常相当差。与 cookie 和表单不同，停止使用凭据是由浏览器控制的（而不是由服务器及其 cookie 控制），但按钮通常最多位于某些高级菜单中（如果它们存在的话）。
There are other forms of authentication supported by browsers, in particular HTTP Basic and HTTP Digest, as well as SSL/TLS client-certificates. Unfortunately, the interface to "log out" when using these mechanisms is usually fairly poor. Unlike cookies and forms, stopping to use the credentials is controlled by the browser (not by the server and its cookies), but the buttons are at best in some advanced menu in general (if they exist at all).
因此，您必须问自己服务器如何区分一个客户端和另一个客户端？在大多数情况下，它是会话 cookie，但也有其他方式。
考虑一个管理应用程序，它被配置为仅在从本地主机访问时才工作。此处，服务器信任浏览器的 IP 地址。现在，如果攻击者创建一个类似
正如布鲁诺已经指出的那样，其他示例包括滥用 Http 基本身份验证和摘要身份验证。
So, you have to ask yourself how does the server know one client from another? In majority of cases, it is the session cookie, but there are other ways as well.
Consider an admin application, that is configured to work only if accessed from localhost. Here, the server is trusting the IP Address of the browser. Now, if an attacker creates a page like
<img src="http://localhost/do/something/harmful"/>, and somehow gets the administrator to visit his page, you have a CSRF.Other examples include abusing Http basic and digest authentication, as Bruno already pointed out.