我已阅读有关 Stack Overflow 的其他问题，但没有找到该问题的明确答案：
是什么阻止了攻击者通过 JS 窃取用户的 CSRF 令牌？难道他不能只找到CSRF元素并用JS获得它的价值吗？
我对 JS 不是很熟悉，但大概是这样的：
document.getElementById("csrft_token").value
【问题讨论】：
标签： javascript security csrf-protection
Java 脚本可以访问您的 DOM 和 Cookie 。
您必须阻止 Intruder 的 Java 脚本在您的用户浏览器上运行（XSS 攻击），
为了防止他们也受到CSRF攻击。
Further information on tokens difference
对于 CSRF 的预防，有两种流行的方法：
为了让攻击者访问 CSRF 令牌，他/她必须将他的 js 注入受害者网页以窃取 CSRF 令牌。这种攻击称为XSS攻击。所以你也要防止XSS攻击。
另一种可能性，是攻击者访问受害者的内存，该内存需要具有内核空间访问权限的恶意软件。
XSRF 保存在 cookie 中，应将 Same-Site Policy 设置为 Lax 或 Strick 以使浏览器不会将其交给其他脚本。
如果系统上的保存的 cookie 文件没有使用所需的权限保护，则其他受害者很容易受到攻击。
【讨论】：
来自 OWASP (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) )
Cross-Site Request Forgery (CSRF) 是一种攻击，它会强制最终用户在当前已通过身份验证的 Web 应用程序上执行不需要的操作。 CSRF 攻击专门针对改变状态的请求，而不是窃取数据，因为攻击者无法看到对伪造请求的响应。借助一些社会工程学的帮助（例如通过电子邮件或聊天发送链接），攻击者可能会诱骗 Web 应用程序的用户执行攻击者选择的操作。如果受害者是普通用户，成功的 CSRF 攻击会迫使用户执行状态更改请求，例如转移资金、更改电子邮件地址等。如果受害者是管理帐户，CSRF 可能会危及整个 Web 应用程序。
根据定义，CSRF 攻击向量与被攻击的服务器不在同一台服务器上，因此它无权访问该信息。
一个基本的例子：
受害者 - 鲍勃
网站 - foo.com
攻击者 - 约翰
John 无法访问 foo.com，但他可以通过网站或电子邮件访问 Bob。他知道 foo.com 的工作原理，因此他可以将请求绑定到电子邮件或不在 foo.com 域中的恶意网站。这将发送请求并搭载 Bob 的凭据。
同源策略可防止 John 查看或拦截 Bob 的 foo.com 版本，这就是为什么 CSRF 密钥可以存储在 Bob 从 foo.com 接收的页面上，而 John 永远不会看到。
如果 John 能够使用 JS 实际看到令牌，则意味着 John 可以访问来自 foo.com 的请求，在这种情况下，这将是中间人攻击或内部攻击。
基本上，CSRF 密钥的目标只是阻止 CSRF 攻击。如果 CSRF 密钥本身被截获，那么就发生了另一次攻击。
【讨论】：
简短的回答是：同源政策。由于攻击者将从另一个来源提供其恶意脚本，因此不允许他的脚本读取包含在另一个来源（即令牌）中的数据。
但是，如果包含令牌的站点存在 XSS 漏洞并且攻击者使用该漏洞来加载他的脚本，那么来源将匹配并且他确实能够窃取他的令牌。
【讨论】：