我遇到了其他几个关于CSRF的问题，但似乎没有一个能回答我的问题。 感觉在CSRF如何工作方面，我缺少一些东西。
请在回答之前阅读整篇文章。
我一直在阅读跨站点请求伪造以及用于减轻和预防它的各种策略(是的，我知道您应该尽可能使用许多(。
但是，提到的主要方法是使用嵌入在网页中的 Nonce/一次性密钥作为隐藏表单参数，所以这就是我关注的。
需要明确的是，我确实理解Nonce试图做什么，但它似乎也很容易被击败。当然，如果攻击者能够向另一个站点发送 POST 请求，他们也可以执行 GET 请求，从页面中抓取令牌，然后将其包含在他们的请求中？
我试图想出一种方法来了解它是如何有用的，但我真的只是不明白它在实践中有什么帮助。
需要明确的是，我并不是想说我知道得更好。 同样，除非我缺少有关CSRF的内容，否则这似乎是一种有效的攻击，并且我没有在任何提供防止CSRF攻击指南的网站上看到它得到解决。
请让我知道我错在哪里。
谢谢！
CSRF 是关于远程攻击者利用用户与网站的会话。
首先，一个蹩脚的例子。您与您的银行进行会话(登录(。登录后，攻击者让您访问他的恶意网站。在恶意网站上，您单击一个很棒的链接以查看您真正想要的内容。但是，恶意网站会向 url 发布正确的数据以将资金转移给攻击者。您不想这样做，您使用的网站似乎与您的银行无关。银行网站仍然收到您的请求，要求将资金转移给攻击者。这是有效的，因为您已经与银行进行了会话，您的会话ID存储在cookie中，并且无论用户单击何处，都会根据目标URL发送cookie(见下文(。这是csrf的基本情况。
因此，如果攻击者让你访问他的恶意网站，为什么他的javascript不能先下载银行页面，然后按照你的建议获得csrf令牌？
那么，为什么他不能只读取您的银行详细信息，帐号，余额？出于同样的原因，Web 浏览器的同源策略(SOP(。如果攻击者网站上的恶意 javascript 向银行 url 发出请求，则请求的来源与其目的地不同。与普遍看法相反，请求仍然会被提出，银行服务器将接收并处理它，并发送响应。但是，您的浏览器将不允许调用 javascript 访问来自不同来源的响应(除非发送 CORS 标头，但这是一个有点不同但相关的主题(。
因此，攻击者在其恶意网站上无法访问受害者用户从不同来源下载的页面，这可以防止您所描述的攻击。攻击者当然可以自己下载银行页面，但csrf令牌在他自己与银行的会话中当然会有所不同。但他无法在受害用户的会话中获取令牌。
换句话说，在页面中生成并在服务器上"记住"的csrf令牌允许服务器检查请求是否来自服务器实际生成的页面。由于 SOP，其他网站无法通过跨域请求访问此令牌。
请注意，上述声明，无论请求来源如何，都会发送cookie，但这并不一定是正确的。Cookie 的全新 SameSite 属性允许对哪些 cookie 应该发送到何处进行一些控制，并且此属性可能会有效地缓解合规浏览器中的CSRF，但会对用户体验产生一些影响。
另请注意，XSS 漏洞确实允许攻击者读取 CSRF 令牌 - 或页面中的任何其他数据。因此，XSS通常被认为是比csrf更严重的缺陷。