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