注册表上是否需要CSRF保护？

Question

Rails默认情况下会自动为所有表单添加CSRF保护,方法是添加authentication_token到站点生成的所有表单.

我真的希望我的网站在网站的首页上有一个简单的注册表单,当然这将是一个静态的HTML页面.理想情况下,这将完全避免攻击Rails堆栈,从而允许我向首页提供更多请求.

这样做的缺点是它使CSRF保护更加困难.

但我想知道是否真的有必要在注册表单上设置CSRF,考虑到CSRF攻击通常依赖于受害者登录,以便可以利用信任.注册表单会记录用户是否正确验证,但我认为这对攻击者没有任何用处.

是否有关于此的建立视图或使用Rails/jQuery的解决方法？

Answer 1

不,对于这种特殊情况不是.CSRF攻击允许攻击者利用受害者拥有的权利,例如bank.com/pay?ammount=1000&to=34.67.978.246

攻击日志形式是没有意义的,因为攻击者可以自己登录,如果他拥有登录字段成功攻击所需的信息(用户名和密码).

Rails在登录领域使用CSRF保护的原因很简单:在95%的字段中全局实施CSRF保护要简单得多;)

Answer 2

关于CSRF

首先,必须明确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保护来实现:

1. 黑客在您实际信任的网站上创建一个帐户(youtrustthis.com)
2. 他使用自己的凭据伪造了浏览器的登录请求,并诱骗您使用他的帐户
3. 如果您没有注意到您实际上正在以另一个用户身份浏览youtrustthis.com,攻击者稍后会看到您"代表他"做了什么,这对您来说几乎是在监视

2:没有CSRF保护,黑客可以在他自己的html文档中模仿您的登录或注册表单,并方便地一次又一次地提交(或者只是使用来自终端的curl),而没有受信任的站点注意到请求没有实际上来自自己 - 即,可信域上的实际登录表单从未在您的浏览器中显示,也没有从那里提交.这使他能够更轻松地执行暴力攻击.如果恶意用户成功尝试查找凭据,您的服务器将使用有效的会话cookie进行响应并信任该用户,通过该用户窃取您的身份.如果它是一个注册表单,他将能够注册大量帐户,从而垃圾邮件您的数据库.

总结一下:使用CSRF保护.恶意用户可以非常使用不安全的登录和注册表单来滥用您的网站并监视您的用户或窃取他们的身份.

有关更多信息,请参阅此类似问题(对于登录表单)和本学术论文.后者在第3页上有关于登录CSRF的专门章节.另外,请查看此CSRF预防备忘单.

关于潜在的解决方法

由于CSRF保护使用会话将服务器端生成的令牌与从表单提交的令牌进行比较,因此我无法想到只在客户端执行此操作的方法,即无需访问Rails堆栈.重点是客户端只有在生成服务器端后才会收到令牌.