某用户在被Rails开发组驳回其漏洞报告之后黑掉了Github网站来演示该漏洞

这是一篇翻译的文章(原文链接),已经是老掉牙的旧闻了,不过感觉这件事很有意思,所以翻译过来。

某用户在被Rails开发组驳回其漏洞报告之后黑掉了Github网站来演示该漏洞

作者:Lucian Constantin, IDG News Service 2012年3月5日

一名用户于上周日黑掉了Ruby on Rails托管在GitHub上代码仓库和Bug跟踪系统,以向Rails开发组展示问题有多么严重。

Ruby on Rails一般简称作Rails,是一种逐渐流行的Ruby语言的Web开发框架,它的设计目标是让开发人员专注于构建应用程序,而无需考虑底层的工作原理。

GitHub是基于Rails框架开发的最受欢迎的Web站点之一,它是一个大型代码托管和协作开发平台,Ruby on Rails项目的代码库和Bug跟踪系统也托管在GitHub上。

上周二,一个名叫Egor Homakov的俄国用户报告了一个Rails框架中存在的漏洞。利用该漏洞,黑客可以从Web表单直接向Rails程序的数据库中注入未经验证的数据,就像SQL注入一样。

这个问题与Rails中的mass assignment功能有关,滥用此功能会导致站点不安全。滥用这一功能的可能性早在几年前就已经知晓,但Rails开发组认为,定义哪些属性可以被这个功能修改的限制条件是应用开发人员的责任。

这个问题的实质是Rails开发人员究竟应该对这一功能应用黑名单策略还是白名单策略。到底是应该默认允许所有属性修改,然后让开发人员定义不许修改的黑名单(现在就是这样的策略);还是应该默认阻止所有属性的修改,再由程序员仔细考虑安全问题之后,定义允许修改的白名单。

很遗憾,历史一再证明把安全决策推给用户极不明智,这往往导致大量的不安全程序在线上运行,这也是Homakov声称问题持续存在了数年的原因。

在尝试说服Rails开发组该功能应该默认关闭未果之后,Homakov决定演示这个漏洞的存在是多么的普遍,即使最成功的Rails应用之一GitHub中也存在这个漏洞导致的安全问题。

星期天,Homakov利用这个漏洞向Ruby on Rails在GitHub上的Bug跟踪系统中加入了一条非法条目,该条目的创建时间居然是1001年后的未来。然后他又利用这个漏洞把他自己的公钥注入GitHub的数据库中,替换了一名Rails开发组成员的的公钥,从而取得了Rails官方代码库的提交权限。

“太平洋时间上午8:49,一名GitHub用户利用公钥更新表单中存在的安全漏洞把他的公钥加入了Rails组织,”——GitHub开发人员Tom Preston-Werner在一篇周日发表的博文中如是说——“后来他推送了一个新文件到该项目中以演示这个安全漏洞。”

GitHub在不到一小时后修复了这个漏洞,并暂时冻结了Homakov的帐号以调查他的行为。GitHub团队在不久后确认了他并无恶意,随即解冻了他的帐号。

“在对攻击行为进行调查的同时,我们对GitHub的代码库展开了彻底的审查,以确保没有其它地方存在相同问题,”Preston-Werner说道“审查工作仍在进行,而我则要确保我们有相应的流程制度避免此类问题再次发生。”

这一事件引起了大量关注,Rails开发组现在愿意更多地讨论这一问题,以期找到解决方案。然而,由于这个问题已经公开,不安全的Rails应用程序遭到攻击的风险也更高了。


我的感想

因为我不是Ruby程序员,所以我也是最近才知道这个发生在三年前的事件。在了解了mass assignment的功能之后,发现这和PHP早年的register global引发的安全问题简直一模一样。在GitHub的讨论中,网友DrPizza的留言很有道理: Insecure-by-default means insecure. (默认设置不安全就意味着不安全)。很难指望程序员在加班加点写完调通功能代码之后再去研究一下手册,发现“啊,我用的方法不安全”一般他们都是直接提交然后就回家睡觉了。只有等到某一天网站被攻击了造成了损失,他可能才会在求助别人之后得知当时犯下了多大的错误。

当年PHP的作法就是从某个版本开始,把register global默认关闭,然后在该项配置旁边写了一堆注释强调开启这个功能的潜在风险,以及不开这个功能的替代方案。

标签: rails, secure

添加新评论