CSRF不是浏览器安全问题吗？
关于跨站点请求伪造 (CSRF) 攻击，如果 Cookie 是最常用的身份验证方法，那么为什么 Web 浏览器允许从另一个域生成的页面发送某个域（并向该域）的 Cookie？
通过禁止此类行为，在浏览器中是否可以轻松预防 CSRF？
据我所知，这种安全检查没有在网络浏览器中实现，但我不明白为什么。 我是不是搞错了什么？
关于 CSRF：
编辑：我认为在上述情况下不应在 http POST 上发送 cookie。 这就是令我惊讶的浏览器行为。
Regarding cross-site request forgery (CSRF) attacks, if cookies are most used authentication method, why do web browsers allow sending cookies of some domain (and to that domain) from a page generated from another domain?
Isn't CSRF easily preventable in browser by disallowing such behavior?
As far as I know, this kind of security check isn't implemented in web browsers, but I don't understand why. Did I get something wrong?
About CSRF:
Edit: I think that cookies should not be sent on http POST in the above case. That's the browser behavior that surprises me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
为什么浏览器不发送cookie？
站点 A (http://www.sitea.com) 为用户设置 cookie。
用户导航到站点 B (http://www.siteb.com)。 站点 B 具有与站点 A 集成的功能 - 单击此处在站点 A 上执行某些操作！ 用户点击“此处”。
据浏览器所知，用户正在有意识地决定向站点 A 发出请求，因此它以与处理向站点 A 的任何请求相同的方式处理该请求，其中包括将请求中的站点 A cookie 发送到站点 A.
编辑：我认为这里的主要问题是您认为身份验证 cookie 和其他 cookie 之间存在区别。 Cookie 可用于存储任何内容 - 用户首选项、您上次的高分或会话令牌。 浏览器不知道每个 cookie 的用途。 我希望我的 cookie 始终可供设置它们的网站使用，并且我希望该网站确保采取必要的预防措施。
或者您是说，如果您在 yahoo 中搜索“gmail”，然后单击链接到 http://mail .google.com，您不应该登录，即使您告诉 gmail 让您保持登录状态，因为您点击了其他网站的链接？
Why wouldn't the browser send cookies?
Site A (http://www.sitea.com) sets a cookie for the user.
User navigates to site B (http://www.siteb.com). Site B features integration with site A - click here to do something on site A! The users clicks "here".
As far as the browser can tell, the user is making a conscious decision to make a request to site A, so it handles it the same way it would handle any request to site A, and that includes sending site A cookies in the request to site A.
Edit: I think the main issue here is that you think there is a distinction between authentication cookies and other cookies. Cookies can be used to store anything - user preferences, your last high score, or a session token. The browser has no idea what each cookie is used for. I want my cookies to always be available to the site that set them, and I want the site to make sure that it takes the necessary precautions.
Or are you saying that if you search yahoo for "gmail", and then click on the link that takes you to http://mail.google.com, you shouldn't be logged in, even if you told gmail to keep you logged in, because you clicked on the link from another site?
这并不是说浏览器将 cookie 发送到外部域或从外部域发送 cookie，而是事实上您已通过身份验证，并且该站点没有验证请求的来源，因此它会将其视为来自外部域的请求。地点。
至于浏览器是否应该禁止这种情况......在许多需要跨站点请求的情况下该怎么办？
编辑：需要明确的是，您的 cookie 不会跨域发送。
It isn't that a browser is sending the cookie to or from an outside domain, it's the fact that you're authenticated and the site isn't validating the source of the request, so it treats it as if the request came from the site.
As far as whether a browser should disallow that... what about the many situations where cross-site requests are desirable?
Edit: to be clear, your cookie is not sent across domains.
我不知道浏览器在这种情况下能做多少事情，因为 XSRF 攻击的目的是将浏览器引导到应用程序中会执行不良操作的另一个点。 不幸的是，浏览器不知道它发送的请求是否是恶意的。 例如，考虑到 XSRF 的经典示例：
浏览器无法明显看出正在发生什么不好的事情。 毕竟，如何知道那个和这个之间的区别：
I don't know that there's much the browser can do in that situation since the point of an XSRF attack is to direct the browser to another point in the application that would perform something bad. Unfortunately, the browser has no idea whether or not the request it's being directed to send is malicious or not. For example, given the classic example of XSRF:
it's not apparent to the browser that something bad is happening. After all, how is it to know the difference between that and this:
许多旧协议都存在很大的安全漏洞 - 回想一下最近发现的 DNS 漏洞< /a>. 就像基本上任何网络安全一样，这是端点的责任； 是的，我们必须自己修复这个问题，这很糟糕，但在浏览器级别修复要困难得多。 有一些明显的情况（
看起来很可疑，对吧？），但总会有边缘情况。 （也许它毕竟是 PHP 文件中的 GD 脚本。） AJAX 查询怎么样？ 等等...
A lot of the old protocols have big security holes -- think back to the recently-discovered DNS vulnerabilities. Like basically any network security, it's the responsibility of the end-points; yeah, it sucks that we have to fix this ourselves, but it's a lot harder to fix at the browser level. There are some obvious ones (<img src="logoff.php"> looks damn fishy, right?), but there will always be edge cases. (Maybe it's a GD script in a PHP file after all.) What about AJAX queries? And so on...
一个站点的 cookie 永远不会发送到另一个站点。 事实上，要实施成功的 CSRF 攻击，攻击者不需要访问这些 cookie。
基本上，攻击者会诱骗已登录目标网站的用户单击链接或加载图像，从而使用该用户的凭据在目标网站上执行某些操作。
即，用户正在执行该操作，而攻击者已欺骗用户这样做。
The cookies for a site are never sent to another site. In fact, to implement a successful CSRF attack, the attacker does not need to have access to these cookies.
Basically, an attacker tricks the user, who is already logged in to the target website, into clicking a link or loading an image that will do something on the target site with that user's credentials.
I.e., the user is performing the action, and the attacker has tricked the user into doing so.
有些人说他们认为浏览器能做的事情不多。
请参阅：
http://people.mozilla。 org/~bsterne/content-security-policy/origin-header-proposal.html
这是关于新 HTTP 标头提案的概述，以帮助减轻 CSRF 攻击。
建议的标头名称是“Origin”，它基本上是“Referer”标头减去路径等。
Some people have said they don't think there's a lot the browser can do.
See this:
http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html
It's an overview of a proposal for a new HTTP header to help mitigate CSRF attacks.
The proposed header name is "Origin" and it's basically the "Referer" header minus the path, etc.