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