关于跨站点请求伪造（CSRF）攻击，如果cookie是最常用的身份验证方法，为什么Web浏览器允许从另一个域生成的页面发送某个域（以及该域）的cookie？
通过禁止此类行为，是否可以在浏览器中轻松预防CSRF？
据我所知，这种安全检查没有在Web浏览器中实现，但我不明白为什么。我弄错了吗？
关于CSRF：
编辑：我认为在上述情况下不应该在http POST上发送cookie。这是令我惊讶的浏览器行为。
答案 0 :(得分：8)
为什么浏览器不发送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始终可用于设置它们的网站，我希望网站确保它采取必要的预防措施。
或者你是说如果你搜索雅虎的“gmail”，然后点击带你到http://mail.google.com的链接，你不应该登录，即使你告诉gmail到让你登录，因为你点击了其他网站的链接？
答案 1 :(得分：4)
浏览器不是将cookie发送到外部域或从外部域发送cookie，这是因为您已经过身份验证且该站点未验证请求的来源，因此它将其视为请求来自网站。
至于浏览器是否应该禁止...那么需要跨站点请求的许多情况呢？
编辑：要清楚，您的Cookie不会跨域发送。
答案 2 :(得分：2)
我不知道浏览器在这种情况下可以做多少事情，因为XSRF攻击的目的是将浏览器指向应用程序中另一个执行不良操作的点。不幸的是，浏览器不知道它被发送的请求是否是恶意的。例如，给出XSRF的经典示例：
<img src="http://domain.com/do_something_bad" />
浏览器并不明白发生了什么不好的事情。毕竟，如何知道它与此之间的区别：
<img src="http://domain.com/show_picture_if_authenticated" />
答案 3 :(得分：2)
许多旧协议都有很大的安全漏洞 - 回想一下最近发现的DNS vulnerabilities。像基本上任何网络安全一样，它是终点的责任;是的，我们必须自己解决这个问题很糟糕，但是在浏览器级别修复它会更加困难。有一些显而易见的（＆lt; img src =“logoff.php”＆gt;看起来该死的，对吗？），但总会有边缘情况。 （毕竟，这可能是PHP文件中的GD脚本。）AJAX查询怎么样？等等...
答案 4 :(得分：1)
网站的Cookie永远不会发送到其他网站。事实上，为了实现成功的CSRF攻击，攻击者无需访问这些cookie。
基本上，攻击者欺骗已经登录到目标网站的用户点击链接或加载图像，该图像将使用该用户的凭据在目标网站上执行某些操作。
即用户正在执行操作，攻击者欺骗用户这样做。
答案 5 :(得分：0)
有些人说他们并不认为浏览器可以做很多事情。
见：
http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html
概述了新HTTP标头的建议，以帮助缓解CSRF攻击。
建议的标题名称是“Origin”，它基本上是“Referer”标题减去路径等。