令牌和跨站点请求伪造

Question

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

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

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

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

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

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

明确地说，我并不是说我知道得更好。尽管如此，除非我遗漏了一些关于 CSRF 的内容，否则这似乎是一种有效的攻击，而且我没有看到任何提供预防 CSRF 攻击指南的网站都解决了它。

请让我知道我错在哪里。

谢谢！

Answer 1

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

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

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

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

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

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

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

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