据我所知，这是一个虚假的错误报告。我认为 Drupal 团队 100% 有权驳回和质疑这个“错误报告”。所谓的“漏洞”对我来说都不是漏洞。仅仅声称某些东西是漏洞并不一定会如此。

记者提出了几个问题：

1. 指控：如果攻击者学习到 CSRF 令牌，他可以击败 CSRF 防御。 嗯，呃。这就是 CSRF 令牌的工作方式。这不是一个漏洞。当我们使用 CSRF 代币时，我们设计系统以避免将代币泄露给攻击者。如果记者发现攻击者可以通过某种方式学习 CSRF 令牌，我们可以讨论它，但事实上，记者一无所有。

2. 指控：注销方法不受 CSRF 令牌保护，因此攻击者可以注销管理员。 这种说法似乎没有根据事实受到质疑，所以我认为它是正确的。但是，强制退出管理员并没有明显的安全后果或危险。在每个构建的 Web 应用程序中，还有其他方法可以强制注销用户，例如，通过超出浏览器 cookie jar 的容量限制。

3. 指控：Drupal 不会始终检查所有请求的referer 标头。 这不是安全漏洞。Referer 标头不应用于安全目的，因为攻击者可以欺骗或强制省略它。记者并未声称 Drupal 的这一特性造成了任何损害。

4. 指控：Drupal 不区分 POST 和 GET 方法。这大概是一个实施不善的案例，但没有记者认定的安全后果，也没有明显的危害。

另请参阅Drupal 组的官方回复。

基本上，我认为原始报告应该被忽略并视为无效，因为未能声称存在有效的安全漏洞。在开源的安全性方面，我没有看到任何基本或其他方面的不足。实际上，我认为 Drupal 团队对指控的反应如此谨慎是值得称赞的。

安全始终是一种权衡。为了获得额外的安全性，您通常必须牺牲便利性、性能或其他一些成本。在这种情况下，Drupal 团队争辩说，增加的安全利益是如此无关紧要，以至于它不保证实施成本。

通过阅读漏洞利用报告，似乎报告了一些“漏洞利用”。一个表明，如果一个人从中间人位置或从受害者自己计算机上的进程进行攻击，他可以利用该位置执行 XSRF 攻击。可以说，这样的攻击者必须拥有如此多的访问权限才能发起这样的攻击，以至于他没有获得任何他还没有的东西。

列出的另一种攻击说，攻击者可以创建一个注销表单，如果受害者提交该表单，它将注销受害者。drupal 团队认为，因为受害者实际上必须发布一个注销表单（这需要经过深思熟虑的行动），并且因为攻击的“有效负载”是简单地将受害者注销，并且由于修复此问题将破坏大多数现有主题，那么获得的安全利益并不能保证修复它会造成的混乱。

最后，报告说，虽然表单具有适当的 XSRF 检查，但该接口并未对所有表单进行 HTTP-Referrer 检查。因此，如果攻击者能够以某种方式捕获 XSRF 令牌，他可以使用它从另一个域发起 XSRF 攻击。drupal 团队认为，XSRF 令牌的全部目的是防止这种类型的攻击，即使没有推荐人检查。他们认为，添加推荐人检查实际上并没有增加更多安全性，但会降低性能和浏览器兼容性。因此，他们认为，这不是问题，也不值得解决。