默认情况下，Rails 会自动为所有表单添加 CSRF 保护，方法是authentication_token向站点生成的所有表单添加一个。
我真的希望我的网站在网站的首页上有一个简单的注册表单，这当然是一个静态 HTML 页面。理想情况下，这将完全避免碰到 Rails 堆栈，从而使我可以向首页提供更多请求。
这样做的缺点是它使 CSRF 保护更加困难。
但我想知道是否真的有必要在注册表单上设置 CSRF 保护，因为 CSRF 攻击通常依赖于受害者登录，以便可以利用信任。如果验证正确，注册表单将使用户登录，但我认为这对攻击者没有任何用处。
对此是否有既定观点或使用 Rails/jQuery 的解决方法？
不，对于这种特定情况不是。CSRF 攻击允许攻击者利用受害者拥有的权利，例如bank.com/pay?ammount=1000&to=34.67.978.246
攻击登录表单是没有意义的，因为如果攻击者拥有对登录字段进行成功攻击所需的信息（用户名和密码），则攻击者可以自行登录。
Rails 在登录字段上使用 CSRF 保护的原因很简单：在全局范围内实现 CSRF 保护要比对 95% 的字段简单得多；）
首先，必须弄清楚 CSRF 到底是什么。
跨站请求伪造 是一种对网站的恶意利用，通过该攻击从网站信任的用户传输未经授权的命令。
考虑以下示例：黑客知道您在 www.example.com 上有一个帐户，假设您已登录该网站，并且仍在运行有效会话。现在，黑客可以引诱您打开另一个网站，例如 trustme.com，他在该网站上发布了带有以下代码的图像：
<img src="http://www.example.com/users/delete"/>
如果 www.example.com 的程序员实际上可以通过简单的 GET 请求通过该 URL 删除您的帐户，并且黑客知道，只需使用您的有效 cookie 查看和加载该图像就会删除您在 example.com 上的帐户，即使您只是浏览 trustme.com，而且这两个网站似乎彼此无关。
总结这个例子，CSRF 利用了站点在用户浏览器中的信任，在本例中是 www.example.com 在您的浏览器中的信任。
对您的案例使用该类比意味着利用您的站点对用户浏览器的信任 - 但该信任尚未建立，因为用户在看到您的表单时尚未登录。但是，您必须确保用户在已经登录并尝试再次使用该表单加载页面时被重定向，否则可以利用建立的信任。
因此，根据经验，每当您使用 cookie 和会话请求验证用户时，即确认或建立对用户的信任时，请使用 CSRF 保护。由于您希望在用户注册时建立对他的信任，因此同样适用。
不幸的是，CSRF 攻击不仅限于此。我发现了另外两件可能发生的事情（当然不限于此）：
1.：以下是监视您的帐户的一个很好的例子，通过省略登录表单上的 CSRF 保护来实现：
2.：如果没有 CSRF 保护，黑客可以在他自己的 html 文档中模仿您的登录或注册表格，并方便地一次又一次地提交（或者只是使用终端上的curl进行），而受信任的站点不会注意到请求没有实际上来自其本身——即，受信任域上的实际登录表单从未显示在您的浏览器中，也没有从那里提交。这使他能够更轻松地执行蛮力攻击。如果恶意用户成功地尝试找出凭据，您的服务器将响应一个有效的会话 cookie 并信任该用户，从而窃取您的身份。如果是注册表单，他将能够注册大量帐户，从而向您的数据库发送垃圾邮件。
总结一下：使用 CSRF 保护。恶意用户可以非常多地使用不安全的登录和注册表单来滥用您的网站并监视您的用户或窃取他们的身份。
有关更多信息，另请参阅此类似问题（用于登录表单）和此学术论文。后者在第 3 页有关于登录 CSRF 的专门章节。另外，请查看此CSRF 预防备忘单。
由于 CSRF 保护使用会话来比较在服务器端生成的令牌与从表单提交的令牌，我想不出一种仅在客户端执行此操作的方法，即不触及 Rails 堆栈。关键是客户端仅在生成服务器端后才收到令牌。
在我看来，从注册表单中关注 csrf 几乎没有技术上的理由。攻击者可以欺骗某人在您的网站上创建一个新帐户 - 如果受害者随后使用您的网站，攻击者可以监视他们的行为，因为他也可以访问该帐户？
更有可能的风险可能是非技术性的。当您的站点获得安全审核时，您必须解释为什么 csrf 在这里没有风险......并且很难证明否定性......“Appscan 已将此标记为严重的安全漏洞 - 为什么不呢？修好它？为什么你不能像查尔斯一样有一个干净的报告？:)
如果你想缓存首页但仍然有 CSRF 保护（这可能是一个好主意，正如 Charles 所说），你可以在页面加载后通过 Javascript 注入适当的真实性令牌。
在http://broadcastingadam.com/2011/05/advanced_caching_in_rails/的“CSRF 和 form_authenticty_token”标题下有一些关于此的信息。相关代码为：
$("meta[name='csrf-token']").attr('content', '<% Rack::Utils.escape_html(request_forgery_protection_token) %>');
$("meta[name='csrf-param']").attr('content', '<% Rack::Utils.escape_html(form_authenticity_token) %>');
使用这种技术，您可以缓存整个主页，但代价是所有客户端都会发出额外的（但非常小且快速）请求来获取此身份验证令牌。
一般来说，保护您的注册表单免受 CSRF 攻击是一个好主意。考虑 Google 搜索，并假设登录表单受到 CSRF 保护，但注册表单易受攻击。攻击者可以强制受害者使用攻击者知道的凭据注册一个新帐户，从那一刻起，受害者所做的任何搜索也将对攻击者可见，因为他知道登录受害者帐户的凭据。这假设易受攻击的站点在注册后立即登录用户。
电子邮件提供商的其他方案是创建用于垃圾邮件目的的帐户。攻击者可以强制受害者创建新帐户，并在注册表中使用 CSRF，并使用这些帐户发送垃圾邮件。这个想法是为了打败基于 IP 或国家/地区限制帐户创建的安全机制。
但是，在特定情况下，可能无法利用易受攻击的注册表单，但是对于该主题的非专家来说，这种分析可能很难。保护表单是个好主意，但是可以创建成功攻击的场景并不多，因此风险通常很低。
是的，所以其他网站无法模仿您的注册表单！就如此容易。
他们可以通过这样做获得什么？