Rails 默认的 CSRF 保护不安全吗？答案

【问题标题】：Is the Rails default CSRF protection insecure?Rails 默认的 CSRF 保护不安全吗？
【发布时间】：2011-02-03 03:45:51
【问题描述】：

默认情况下，Rails 中的表单 post CSRF 保护会为用户创建一个真实性令牌，该令牌仅在用户会话更改时才会更改。我们的一位客户对我们的网站进行了安全审核，并将其标记为问题。

审计员的声明是，如果我们也有一个 XSS 漏洞，那么攻击者可以获取另一个用户的真实性令牌并将其用于 CSRF 攻击，直到用户的会话过期。

但在我看来，如果我们有这样的 XSS 漏洞，攻击者可以像直接获取另一个用户的会话 cookie 并直接登录一样容易。或者甚至只是在用户受到攻击时从脚本调用我们的 REST Api。在这种情况下，能够发起 CSRF 攻击似乎并没有变得更糟……问题在于 XSS 漏洞。

我错过了什么吗？ Rails 中默认的 CSRF 保护是否存在真正的问题？

【问题讨论】：

请注意 CSRF for Rails 中的一个漏洞被发现并存在于 Rails 3.0.3 及以下版本中。见weblog.rubyonrails.org/2011/2/8/…。升级到 3.0.4 以确保解决此问题。
附带说明，会话 cookie 应设置为 HttpOnly，这样它们就不会被 XSS 窃取。

【解决方案1】：

你完全正确。基于令牌的 CSRF 保护是最常见的，只要您针对 XSS 测试应用程序就可以了。

在某些情况下，CSRF 仍然可以被停止而不管 XSS。例如，对于您的密码更改论坛，要求他们知道当前密码。除非他知道当前密码，否则黑客将无法伪造此请求，这是一个有争议的问题。

另一种方法是要求验证码来解决该请求。我推荐使用 reCapthca。

【讨论】：

从技术上讲，如果您的表单除了需要其他数据外还需要用户输入密码，那么您不是在保护 CSRF 或 XSS，而是防止会话被盗。 CSRF 攻击是关于能够使用当前浏览器会话的凭据在另一个站点上执行命令。
请注意，如果您有 XSS 漏洞和要求用户输入非 OTP 密码的表单，攻击者只是获得了用户的密码！
@Mikko Rantalainen 这将是网络钓鱼，而不是 CSRF。您可以使用 xss 将页面正文重写为接受密码的论坛。但是如果在其他页面上有表单要求输入密码，那么 XSS 就不能用于读取该密码，因为它不能用 XHR 读取。
您说得对，需要用户输入密码的页面上的 XSS 漏洞才能在不进行网络钓鱼的情况下获取密码。此外，如果您在网站的每个页面上都嵌入了登录表单（现在像往常一样），任何 XSS 漏洞都可能导致用户密码暴露（使用 XSS 在其他地方使用 XHR 静默提交被盗的登录名/密码）。
@Mikko Rantalainen 重写 onsubmit 处理程序以将用户名/密码传输到攻击者的服务器。