窃取CSRF代币

Cur*_*Guy 3 javascript security csrf-protection

我已经阅读了有关Stack Overflow的其他问题,但没有找到明确的答案:

是什么阻止了攻击者通过JS窃取用户的CSRF令牌?他不能仅仅找到CSRF元素并用JS获得它的价值吗?

我对JS不太熟悉,但也许像这样:

document.getElementById("csrft_token").value
Run Code Online (Sandbox Code Playgroud)

Com*_*ass 6

从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接收的Bob页面上而不会被John看到的原因。

如果John能够使用JS实际看到令牌,则意味着John可以访问foo.com的请求,在这种情况下,这可能是中间人攻击或内部人攻击。

基本上,CSRF密钥的目标是仅停止CSRF攻击。如果CSRF密钥本身被截获,则发生了另一次攻击。


dan*_* f. 6

简短的回答是:同源策略。由于攻击者会从另一个源提供其恶意脚本,因此不允许他的脚本读取另一个源中包含的数据(即令牌)。

但是,如果包含令牌的站点存在 XSS 漏洞,并且攻击者利用该漏洞加载其脚本,则来源将匹配,并且他确实能够窃取其令牌。