我已经阅读了有关Stack Overflow的其他问题,但没有找到这个问题的明确答案:
什么阻止攻击者通过JS窃取用户的CSRF令牌?难道他不能只找到CSRF元素并用JS获得它的价值吗?
我对JS不是很熟悉,但也许是这样的:
document.getElementById("csrft_token").value
来自OWASP(https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF))
跨站点请求伪造(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漏洞且攻击者使用该漏洞加载其脚本,则源将匹配,并且他确实能够窃取其令牌。