关于跨站点请求伪造 (CSRF) 攻击,如果 cookie 是最常用的身份验证方法,为什么 Web 浏览器允许从另一个域生成的页面发送某个域(以及该域)的 cookie?
通过禁止这种行为,CSRF 在浏览器中是否可以轻松预防?
据我所知,这种安全检查并没有在网络浏览器中实现,但我不明白为什么。我是不是搞错了什么?
关于 CSRF:
编辑:我认为在上述情况下不应在 http POST 上发送 cookie。这就是让我吃惊的浏览器行为。
为什么浏览器不发送cookies?
站点 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 保留你登录,因为您点击了另一个站点的链接?
并不是浏览器将 cookie 发送到外部域或从外部域发送 cookie,而是您已通过身份验证并且站点未验证请求的来源,因此它将其视为请求来自地点。
至于浏览器是否应该禁止这样做……在许多需要跨站点请求的情况下呢?
编辑:需要明确的是,您的 cookie 不会跨域发送。
我不知道在这种情况下浏览器可以做很多事情,因为 XSRF 攻击的目的是将浏览器引导到应用程序中会执行不良操作的另一个点。不幸的是,浏览器不知道它被引导发送的请求是否是恶意的。例如,给定 XSRF 的经典示例:
<img src="http://domain.com/do_something_bad" />
浏览器看不出有什么不好的事情发生了。毕竟,如何知道that和this之间的区别:
<img src="http://domain.com/show_picture_if_authenticated" />
许多旧协议都有很大的安全漏洞——回想一下最近发现的DNS 漏洞。就像基本上任何网络安全一样,它是端点的责任;是的,我们必须自己解决这个问题很糟糕,但是在浏览器级别修复要困难得多。有一些明显的情况(<img src="logoff.php"> 看起来很可疑,对吧?),但总会有边缘情况。(也许它毕竟是 PHP 文件中的 GD 脚本。) AJAX 查询呢?等等...
一个站点的 cookie 永远不会发送到另一个站点。事实上,要实施成功的 CSRF 攻击,攻击者不需要访问这些 cookie。
基本上,攻击者欺骗已经登录到目标网站的用户单击链接或加载图像,该图像将使用该用户的凭据在目标站点上执行某些操作。
即,用户正在执行该操作,而攻击者已诱骗用户这样做。
有些人说他们不认为浏览器可以做很多事情。
看到这个:
http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html
这是对新 HTTP 标头提案的概述,以帮助减轻 CSRF 攻击。
建议的标题名称是“Origin”,它基本上是“Referer”标题减去路径等。