首页 > 解决方案 > 令牌和跨站点请求伪造

问题描述

我遇到了其他几个关于 CSRF 的问题,但似乎没有人回答我的问题。感觉在 CSRF 的工作方式方面我缺少一些东西。

请在回答之前阅读整个帖子。

我一直在阅读跨站点请求伪造以及用于减轻和防止它的各种策略(是的,我知道您应该尽可能多地使用)。

然而,主要提到的是使用嵌入在网页中的 Nonce/One Time Key 作为隐藏的表单参数,所以这就是我所关注的。

需要明确的是,我确实理解 Nonce 试图做什么,但它似乎也很容易被打败。当然,如果攻击者能够向另一个站点发送 POST 请求,他们也可以发出 GET 请求,从页面中抓取令牌,然后将其包含在他们的请求中?

我试图想出一种方法来看看它是如何有用的,但我真的不知道它在实践中有何帮助。

需要明确的是,我并不是想说我知道得更好。尽管如此,除非我遗漏了一些关于 CSRF 的信息,否则这似乎是一种有效的攻击,而且我没有看到任何提供防止 CSRF 攻击指南的网站上解决了它。

请让我知道我错在哪里。

谢谢!

标签: securityrequestcsrfcross-site

解决方案


CSRF 是关于远程攻击者利用用户与网站的会话。

首先,一个蹩脚的例子。您与您的银行进行会话(登录)。登录后,攻击者让您访问他的恶意网站。在恶意网站上,您单击一个很棒的链接以查看您真正想要的东西。但是,恶意网站会将正确的数据发布到 URL 以将资金转移给攻击者。您不想这样做,而且您使用的网站似乎与您的银行无关。银行网站仍然收到您向攻击者汇款的请求。这是可行的,因为您已经与银行进行了会话,您的会话 ID 存储在 cookie 中,并且无论用户点击何处,cookie 都会根据目标 url 发送(见下文)。这是 csrf 的基本情况。

所以如果攻击者让你访问他的恶意网站,为什么他的javascript不能先下载银行页面,然后按照你的建议获取csrf令牌?

好吧,他为什么不能只看你的银行信息、帐号和余额?出于同样的原因,Web 浏览器的同源策略(SOP)。如果攻击者网站上的恶意 javascript 向银行 url 发出请求,则请求的来源与目的地不同。与通常的看法相反,请求仍然会发出,银行服务器会接收并处理它,然后发送响应。但是,您的浏览器将不允许调用 javascript 访问来自不同来源的响应(除非发送了 CORS 标头,但这有点不同,但相关主题)。

因此,他的恶意网站上的攻击者无法访问受害者用户从不同来源下载的页面,这可以防止您描述的攻击。攻击者当然可以继续自己下载银行页面,但 csrf 令牌在他自己与银行的会话中当然会有所不同。但他无法在受害者用户的会话中获取令牌。

换句话说,在页面中生成并在服务器上“记住”的 csrf 令牌允许服务器检查请求是否来自服务器实际生成的页面。由于 SOP,其他网站无法通过跨域请求访问此令牌。

请注意,上面关于无论请求来源如何都会发送 cookie 的声明并不一定是正确的。cookie 的新的 SameSite 属性允许对应该将哪些 cookie 发送到何处进行一些控制,并且该属性可以有效地缓解兼容浏览器中的 CSRF ,并具有一些 UX 影响。

另请注意,XSS 漏洞确实允许攻击者读取 CSRF 令牌 - 或页面中的任何其他数据。因此,XSS 通常被认为是比 csrf 更严重的缺陷。


推荐阅读