首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 网络技术 > 网络基础 >

ruby和rails的安全性有关问题学习

2012-09-07 
ruby和rails的安全性问题学习因为在论坛http://www.ruby-lang.org.cn/上有drive2me兄问rails的安全性如何,

ruby和rails的安全性问题学习
因为在论坛http://www.ruby-lang.org.cn/上有drive2me兄问rails的安全性如何,而我也不是很了解,所以
在网络上学习了一下,下面就是一些总结,一来是帮助drive2me兄,回答他的问题,一来也是备忘,希望有更多人研究rails的安全性,写出更安全的webapp。

1. ruby的安全机制
  参考《programming ruby》中的Locking ruby in safe一章。
  主要说明了安全级别和脏对象。

  脏对象(tainted object):所有外部数据都是危险的,比如对表单提交的数据进行eval操作就会造成很严重的安全问题。

  所有从外部进入的ruby解释器的数据都可以被标记为脏对象(tainted),
  当ruby解释器运行在某一个安全模式下时,有危险的方法调用将导致系统抛出SecurityException.

  变量$SAFE决定ruby的“怀疑级别”。数字越低越不安全。
  $SAFE=0   让ruby不检查外部提供的脏(tainted)数据的使用情况,这是ruby的默认模式。
  $SAFE>=1  让ruby不允许脏(tainted)数据使用可能有危险的方法,比如eval。
  $SAFE>=2  让ruby不允许从全局可写位置装载程序。
  $SAFE>=3  让ruby把所有新创建的对象都认为是脏的(tainted).并且不能把一个脏对象untaint.
  $SAFE>=4  让ruby有效地把正在运行的程序划分成两部分,脏的和干净的。

  $SAFE变量一旦设置了一个值,就不可能再设置为更低的值了。
  $SAFE值是线程独立的,新线程会继承当前的$SAFE值,但是新线程可以修改这个值,而其它线程不受影响。
  使用这个机制可以实现一个沙盒,用来运行外部的程序。例如:
   

    解决办法: 

    解决办法:关闭目标服务器上可能造成CSS攻击的echo服务和其它服务(FTP,POP3等)。

    有专门的网站记录CSS攻击事件:http://www.xssed.com/

  = Session hijacking (session 劫持):
  攻击者通过 sniffing 不安全网络,获取别人的cookie.然后使用该cookie登录目标网站。

    解决办法:
    *告诉浏览器传送cookie时使用ssl.
    
ff方法关闭所有method的session产生。
  *在成功登录后,创建一个新的session. reset_session.
  *有效地设置cookie的过期时间。

  = Cross-site Request Forgery (跨站请求伪造)
  攻击者设法让受害者打开一个网页,或者打开一封邮件,其中有图片链接,这个链接会让用户向他已经登录的网站发起一个
  请求,来做一些受害者不知道的事情,比如修改密码、下订单、删除数据等等。攻击用的url类似:
  <img  src="http://www.application.com/order/20/delete" />

  解决办法:
  *正确使用GET/POST方法,GET读取数据,POST修改数据。
  *使用CSRF-KILLER插件为请求加上token(令牌).


3. rails自身使用不当造成的安全隐患(mass-assignment problem)
  = 直接用表单创建记录, 也被称作 mass-assignment 问题
  普通的写法:
   

    User.create(@params['user'])
  恶意代码:
   

  解决办法:
    attr_protected, 加手工赋值, user.approved = sanitize_properly(@params['user']['approved'])
    attr_accessible :name, :password, 让rails默认情况下不让任何属性能够"mass-assignment"除非
      显式地说明该属性可以批量访问(mass-assignment)。

  = rails自身的安全问题:
  http://blog.evanweaver.com/articles/2006/08/12/anatomy-of-an-attack-against-1-1-4/

4. help tools
  safeERB
  csrf-killer

5. 我的结论
  rails提供了很多安全方面的功能,所以开发一个安全的webapp用rails会比其它webapp框架容易。
  webapp面临的大都数安全问题是共有的,并非应用rails而造成的,反而rails提供的很多安全化手段可以让webapp变得
  更加安全。

  当然rails和ruby程序自身也有一些安全隐患,但并不是致命和不可克服的,需要紧跟rails和ruby官方网站发布的安全
  声明。

参考资料:
  <<programming ruby 2nd>> (Table 25.1. De?nition of the safe levels)
  http://www.rorsecurity.info/ruby-on-rails-security-cheatsheet/
  http://ianloic.com/insecurity_is_ruby_on_rails_best_practice
  http://www.lonerunners.net/blog/archives/1028-Rails-Security-Secure-your-Ruby-on-Rails-web-application.html
  http://sonjayatandon.com/05-2006/how-to-build-a-secured-web-application-with-ruby-on-rails/
  http://manuals.rubyonrails.com/read/chapter/47
  http://erlend.oftedal.no/blog/?blogid=20
  http://manuals.rubyonrails.com/read/book/8
  http://www.slideshare.net/amiable_indian/ruby-on-rails-security
出处:http://blog.csdn.net/yangbo_hr/article/details/2008183

热点排行