为啥没有更多的控制器由于未使用 skip_forgery_protection 而失败？

Posted 2023-03-10

【中文标题】为啥没有更多的控制器由于未使用 skip_forgery_protection 而失败？

【英文标题】：Why aren't more of my controllers failing due to skip_forgery_protection not being used?为什么没有更多的控制器由于未使用 skip_forgery_protection 而失败？

【发布时间】：2021-12-08 10:28:40

【问题描述】：

我正在将 Rails 应用程序从 5.2 升级到 6.1。以前我使用的是 5.1 默认值，现在我使用的是 6.1 默认值。

在 rails 5.2 中，伪造保护成为默认设置。所以，当我一路升级到 6.1 时，一些事情开始出现问题。

我将 skip_forgery_protection 添加到我的 graphql 控制器中，这修复了我所有失败的测试。没有测试访问其他控制器（肯定没有在前端实现伪造系统）失败，我手动尝试的其他事情也没有。

我的一个理论是 forgery_protection 仅适用于 POST、PUT、PATCH 和 DELETE，但我发现网上对此的讨论或提及为零，这似乎不是我所观察到的（尽管我承认我没有尚未彻底测试该理论）。

一切都继承自同一个ApplicationController

会发生什么？

【参考方案1】：

我不确定我是否正确理解了您的问题。

但是，如果您问为什么 forgery_protection 仅适用于 POST、PUT、PATCH 和 DELETE，那么 doc says，

Turn on request forgery protection. Bear in mind that GET and HEAD requests are not checked.

来自wikipedia，

特别是，已经建立了约定，即 GET 和 HEAD 方法不应具有采取除检索之外的操作的意义。这些方法应该被认为是“安全的”。这允许用户代理以特殊的方式表示其他方法，例如 POST、PUT 和 DELETE，以便让用户意识到正在请求可能不安全的操作。

由于这个假设，Web 框架中的许多现有 CSRF 预防机制不会涵盖 GET 请求，而是仅将保护应用于旨在改变状态的 HTTP 方法。