我正在遇到有关Rails中的Authenticity Token的一些问题,因为我现在已经多次了.
但我真的不想只是解决这个问题而继续下去.我真的很想了解真实性令牌.那么,我的问题是,您是否有关于此主题的完整信息来源,或者您是否会花时间在此详细解释？
怎么了
当用户查看表单以创建,更新或销毁资源时,Rails应用程序会创建一个随机的authenticity_token,将此令牌存储在会话中,并将其放在表单中的隐藏字段中.当用户提交表单时,Rails查找authenticity_token,将其与存储在会话中的那个进行比较,如果匹配则允许继续.
为什么会这样
由于真实性令牌存储在会话中,因此客户端无法知道其值.这可以防止人们在不查看该应用程序本身内的表单的情况下向Rails应用程序提交表单.想象一下,您正在使用服务A,您登录该服务,一切正常.现在想象一下你去使用服务B,你看到了你喜欢的图片,并按下图片来查看更大尺寸的图片.现在,如果服务B上有一些恶意代码,它可能会向服务A发送请求(您已登录),并通过发送请求来要求删除您的帐户http://serviceA.com/close_account.这就是所谓的CSRF(Cross Site Request Forgery).
如果服务A使用真实性令牌,则此攻击向量不再适用,因为来自服务B的请求将不包含正确的真实性令牌,并且将不允许继续.
API文档描述了有关元标记的详细信息:
使用该
protect_from_forgery方法打开CSRF保护,该方法检查令牌并在会话与预期不匹配时重置会话.默认情况下,会为新的Rails应用程序生成对此方法的调用.token参数authenticity_token默认命名.必须通过csrf_meta_tags在HTML头中包含来将此标记的名称和值添加到呈现表单的每个布局中.
笔记
请记住,Rails只验证非幂等方法(POST,PUT/PATCH和DELETE).不检查GET请求的真实性令牌.为什么？因为GET请求的HTTP规范状态是幂等,应该不是在服务器上创建,修改或破坏资源,应该将请求幂等(如果您运行相同的命令多次,你应该每次都得到相同的结果).
此外,真正的实现在开始时定义更复杂,确保更好的安全性.Rails不会为每个表单发出相同的存储令牌.它也不是每次都生成和存储不同的令牌.它在会话中生成并存储加密哈希,并发布新的加密令牌,每次呈现页面时,可以与存储的加密令牌进行匹配.请参阅request_forgery_protection.rb.
教训
使用authenticity_token来保护您不幂等的方法(POST,PUT/PATCH和DELETE).还要确保不允许任何可能修改服务器上资源的GET请求.
编辑:检查@erturne关于GET请求是幂等的评论.他以比我在这里做的更好的方式解释它.
真品令牌旨在让您知道您的表单是从您的网站提交的.它是从运行它的机器生成的,具有唯一的标识符,只有您的机器可以知道,从而有助于防止跨站点请求伪造攻击.
如果您只是在使用rails拒绝访问AJAX脚本时遇到困难,可以使用
<%= form_authenticity_token %>
在创建表单时生成正确的标记.
您可以在文档中阅读更多相关信息.
真实性令牌是跨站请求伪造(CSRF)的对策.你问什么是CSRF？
这是攻击者可能在不知道会话令牌的情况下劫持会话的方式.
场景:
访问您银行的网站,登录.
然后访问攻击者的网站(例如,来自不受信任的组织的赞助广告).
攻击者的页面包含与银行"转移资金"表单相同字段的表单.
攻击者知道您的帐户信息,并预先填写了表单字段,以便将资金从您的帐户转移到攻击者的帐户.
攻击者的页面包含向您的银行提交表单的Javascript.
表单提交后,浏览器会包含您的银行网站的Cookie,包括会话令牌.
银行将钱转移到攻击者的帐户.
表单可以在不可见的iframe中,因此您永远不会知道发生了攻击.
这称为跨站请求伪造(CSRF).
CSRF解决方案:
服务器可以标记来自服务器本身的表单
每个表单必须包含一个额外的身份验证令牌作为隐藏字段.
令牌必须是不可预测的(攻击者无法猜测).
服务器在其页面中的表单中提供有效令牌.
服务器在发布表单时检查令牌,拒绝没有适当令牌的表单.
示例令牌:使用服务器密钥加密的会话标识符.
Rails自动生成这样的标记:请参阅每个表单中的authenticity_token输入字段.
可以防止的最小攻击示例
在我的网站上,evil.com我说服你提交以下表格:
如果您通过会话cookie登录银行,那么将发送cookie并在您不知情的情况下进行转移.
那就是CSRF令牌发挥作用:
使用返回表单的GET响应,Rails发送一个非常长的随机隐藏参数
当浏览器发出POST请求时,它会发送参数,服务器只有在匹配时才接受它
因此,真实浏览器上的表单如下所示:
因此,我的攻击会失败,因为它没有发送authenticity_token参数,并且我无法猜到它,因为它是一个巨大的随机数.
这种预防技术称为同步器令牌模式.
同步器令牌模式因同源策略而起作用:如果我可以向您的银行发出XHR GET请求form_tag,并且读取结果,我将能够只读取令牌然后再发出请求.我已在以下网址进一步解释:https://security.stackexchange.com/a/72569/53321
我强烈建议您阅读OWASP指南,关于此问题以及任何其他安全问题.
Rails如何发送令牌
涵盖在:Rails:csrf_meta_tag如何工作？
基本上:
HTML帮助程序meta,如果它不是GET表单,则为表单添加隐藏字段
AJAX由jquery-ujs自动处理,它csrf_meta_tags通过X-Requested-With(存在于默认模板中)添加到标题中的元素读取标记,并将其添加到任何请求中.
uJS还尝试在过时的缓存片段中更新表单中的标记.
其他预防方法
检查是否存在某些标题,例如Origin:
X-Requested-With标头有什么意义？
https://security.stackexchange.com/questions/23371/csrf-protection-with-custom-headers-and-without-validating-token
X-Requested-With标头服务器检查是否足以防止ajax驱动的应用程序的CSRF？
检查evil.com标题的值:https://security.stackexchange.com/questions/91165/why-is-the-synchronizer-token-pattern-preferred-over-the-origin-header-check-to
重新认证:再次询问用户密码.这应该针对每个关键操作(银行登录和汇款,大多数网站的密码更改)进行,以防您的网站获得XSS.缺点是用户必须多次输入密码,这很烦人,并且增加了键盘记录/肩上冲浪的机会.
的Authenticity Token是轨道的方法,以防止 '跨站请求伪造(CSRF或XSRF)攻击’.
简单来说,它确保您的Web应用程序的PUT/POST/DELETE(可以修改内容的方法)请求来自客户端的浏览器,而不是来自可以访问创建的cookie的第三方(攻击者)在客户端.
真实性令牌用于防止跨站点请求伪造攻击(CSRF).要了解真实性令牌,您必须首先了解CSRF攻击.
CSRF假设您是作者bank.com.您的网站上有一个表单,用于通过GET请求将资金转帐到其他帐户:
黑客可以向服务器发送HTTP请求GET /transfer?amount=$1000000&account-to=999999,对吧？
错误.黑客攻击不起作用.服务器基本上会想到吗？
咦？这个人试图启动转移是谁.它不是帐户的所有者,这是肯定的.
服务器如何知道这一点？因为没有session_idcookie验证请求者.
当您使用用户名和密码登录时,服务器会session_id在您的浏览器上设置cookie.这样,您就不必使用您的用户名和密码对每个请求进行身份验证.当您的浏览器发送session_idcookie时,服务器知道:
哦,那是John Doe.他在2.5分钟前成功登录.他很高兴.
黑客可能会想:
嗯.普通的HTTP请求不起作用,但是如果我能抓住那个
session_idcookie,我就会变得很好.
用户浏览器为bank.com域设置了一堆cookie .每次用户向bank.com域发出请求时,都会发送所有cookie.包括session_idcookie.
因此,如果黑客可以让你做出将资金转入他账户的GET请求,他就会成功.他怎么会欺骗你这样做？使用跨站点请求伪造.
实际上,它非常简单.黑客可以让你访问他的网站.在他的网站上,他可以有以下图片标签:
好吧,只是不要访问危险的网站,你会没事的.
这还不够.如果有人将该图片发布到Facebook并且它出现在您的墙上会怎么样？如果它被注入你正在访问XSS攻击的网站怎么办？
也不是那么坏.只有GET请求容易受到攻击.
不对.可以动态生成发送POST请求的表单.以下是Rails安全指南中的示例:
To the harmless survey真实性令牌当你
ApplicationController有这个:protect_from_forgery with: :exception这个:
<%= form_tag do %> Form contents <% end %>编译成这样:
特别是,生成以下内容:
为了防止CSRF攻击,如果Rails没有看到与请求一起发送的真实性令牌,它将不会认为请求是安全的.
攻击者如何知道这个令牌是什么？每次生成表单时都会随机生成一个不同的值:
跨站点脚本(XSS)攻击 - 就是这样.但这是另一天的不同漏洞.
因为Authenticity Token非常重要,在Rails 3.0+中你可以使用
<%= token_tag nil %>
创造
随地
如果您有来自同一客户端的多个并发请求,请注意真实性令牌机制可能导致竞争条件.在这种情况下,当应该只有一个时,您的服务器可以生成多个真实性令牌,并且在表单中接收先前令牌的客户端将在其下一个请求上失败,因为会话cookie令牌已被覆盖.这里有一个关于这个问题的文章和一个非常简单的解决方案:http: //www.paulbutcher.com/2007/05/race-conditions-in-rails-sessions-and-how-to-fix-them/
方法authenticity_token需要的地方
authenticity_token在幂等方法(如post,put和delete)的情况下是必需的,因为Idempotent方法正在影响数据.
为什么需要它
它需要防止邪恶的行为.authenticity_token存储在会话中,只要在网页上创建表单以创建或更新资源,则真实性令牌存储在隐藏字段中,并在服务器上与表单一起发送.在执行操作之前,用户发送的authenticity_token与
authenticity_token存储在会话中交叉检查.如果authenticity_token相同则继续进程,否则不执行操作.
什么是authentication_token？
这是Rails应用程序使用的随机字符串，用于确保用户正在从应用程序页面而不是从另一个应用程序或站点请求或执行操作。
为什么需要authentication_token？
为了保护您的应用程序或站点免受跨站点伪造。
如何在表格中添加一个authentication_token？
如果您使用form_for标记生成表单，则会自动添加authentication_token，您可以使用<%= csrf_meta_tag %>。
京公网安备 11010802040832号 | 京ICP备19059560号-6 