Security 令牌和跨站点请求伪造

关于CSRF，我还遇到了其他几个问题，但似乎没有一个能回答我的问题。就CSRF的工作原理而言，我觉得我缺少了一些东西

请在回答之前阅读全文

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

然而，主要提到的是使用嵌入在网页中的Nonce/one-Time键作为隐藏的表单参数，所以这就是我重点关注的

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

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

说清楚一点，我不是想说我知道得更多。尽管如此，除非我遗漏了一些关于CSRF的信息，否则这似乎是一种有效的攻击，而且我看不到任何网站提供了防止CSRF攻击的指南

请告诉我哪里错了

---

谢谢

CSRF是一个远程攻击者利用用户与网站的会话进行攻击

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

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

好吧，为什么他不能看一下你的银行资料，账号，余额？出于同样的原因，web浏览器的同源策略（SOP）。如果攻击者网站上的恶意javascript向银行url发出请求，则该请求的来源与其目的地不同。与通常的想法相反，请求仍然会被发出，银行服务器将接收并处理它，然后发送响应。但是，您的浏览器将不允许调用javascript访问来自不同来源的响应（除非发送CORS头，但这是一个稍微不同但相关的主题）

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

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

请注意，上面关于发送cookie而不考虑请求来源的声明不一定正确。Cookie的新ish SameSite属性允许对哪些Cookie应该发送到哪里进行一些控制，并且该属性可能有效地缓解兼容浏览器中的CSRF，并带来一些UX影响

---

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

。很好的解释，加博。非常感谢。我知道我错过了什么。