谁来为漏洞买单?【转】

昨天介绍了一下PHP中is_a()函数功能改变引发的问题,后来发现很多朋友不认同这是一个漏洞,原因是这是通过良好的代码习惯能够避免该问题,比如写一个安全的__autoload()函数。

我觉得我有必要讲讲一些安全方面的哲学问题,但这些想法只代表我个人的观点,是我的安全世界观。

互联网本来是安全的,自从有了研究安全的人,就变得不安全了。

所有的程序本来也没有漏洞,只有功能,但当一些功能被用于破坏,造成损失时,也就成了漏洞。

我们定义一个功能是否是漏洞,只看后果,而不应该看过程

    计算机用0和1定义了整个世界,但在整个世界中,并非所有事情都能简单用”是“或者”非“来判断,漏洞也是如此,因为破坏有程度轻重之分,当破坏程度超过某一临界值时,会被多数人(注意不是所有人),接受为这是一个漏洞的事实。但事物是变化的,这个临界值也不是一成不变的,”多数人“也不是一成不变的,所以我们要用变化的观点去看待变化的事物。

 

泄露用户个人信息,比如电话、住址,在以前几乎称不上漏洞,因为没有人利用;但在互联网越来越关心用户隐私的今天,这就变成了一个严重的问题,因为有无数的坏人时刻在想着利用这些信息搞破坏,非法攫取利益。所以今天如果发现某网站能够批量的、未授权的获取到用户个人信息,这就是一个漏洞。

 

再举个例子,用户登录的memberID是否属于机密信息?在以往做信息安全,我们都只知道”密码“、”安全问题“等传统意义上机密信息需要保护。但是在今天,网站的业务设计中,我们发现loginID也应该属于需要保护的信息。因为loginID一旦泄露后,可能会导致被暴力破解;甚至由于有的用户将loginID当成了密码的一部分,会被黑客中猜测用户的密码;或者是黑客通过攻击一些第三方站点(比如SNS)后,找到同样的loginID来尝试登录。

正因为攻击技术也在发展,所以我们对漏洞的定义也在不断发生变化。可能很多朋友都没有注意到,一个业务安全设计的好的网站,往往loginID和nickname(昵称)是分开的。登录ID是用户的私有信息,只有用户本人能够看到;而nickname不能用于登录,但可以公开给所有人看。这种细节的设计,是网站积极防御的一种表现。

 

可能很多朋友仍然不愿意承认这些问题是漏洞,那么什么是漏洞呢?在我看来,漏洞只是对破坏性功能的一个统称而已

 

但是”漏洞“这顶帽子太大,大到我们难以承受,所以我们不妨换一个角度看,看看是否“应该修补”。语言真是很神奇的东西,很多时候换一个称呼,就能让人认可度提高很多。

 

在PHP的5.3.4版本中,修补了很多年来万恶的0字节截断功能,这个功能被用于文件包含漏洞的利用,酿造了无数血案。

我们知道PHP中include/require一个文件的功能,如果有良好的代码规范,是安全的,不会成为漏洞。

这是一个正常的PHP语言的功能,只是”某一群不明真相的小白程序员“在一个错误的时间,错误的地点写出了错误的代码,使得”某一小撮狡猾的黑客“发现了这些错误的代码,从而导致漏洞。这是操作系统的问题,谁叫操作系统在遍历文件路径的时候会被0字节截断,谁叫C语言的string操作是以0字节为结束符,谁叫程序员写出这么小白的代码,官方文档里已经提醒过了,关PHP什么事情,太冤枉了!

我也觉得PHP挺冤枉的,但C语言和操作系统也挺冤的,我们就是这么规定的,如之奈何?

但总得要有人来为错误买单,谁买单呢?写出不安全代码的小白程序员?

No!学习过市场营销方面知识的同学应该知道,永远也别指望让最终用户来买单。就像老百姓不应该为政府的错误买单一样(当然在某个神奇的国度除外)。所以必须得有人为这些不是漏洞,但造成了既成事实的错误负责,我们需要有社会责任感的owner

很高兴的是PHP官方在经历这么多年纠结,折磨,发疯之后,终于勇敢的承担起了这个责任(我相信这是一个很坎坷的心路历程),为这场酿成无数惨案的闹剧划上了一个句号。但是我们仍然悲观的看到,cgi.fix_pathinfo的问题仍然没有修改默认配置,使用fastcgi的PHP应用默认处于风险中。PHP官方仍然坚持认为这是一个正常的功能,谁叫小白程序员不认真的学习官方文件精神!是啊,无数网站付出惨痛学费的正常功能!

 

    PHP是当下用户最多的Web开发语言之一,但是因为种种历史遗留原因(我认为是历史原因),导致在安全的”增值“服务上,做的远远不够(相对于一些新兴的流行语言来说)。在PHP流行起来的时候,当时的互联网远远没有现在复杂,也远远没有现在这么多的安全问题,在当时的历史背景下,很多问题都不是”漏洞“,只是功能。

但我们也可以预见到,在未来互联网发展的过程中,也必然会有更多、更古怪的攻击方式出现,也必然会让更多的原本是”功能“的东西,变成漏洞。

 

最后,也许你已经看出来了,我并不是要说服谁is_a()是一个漏洞,而是在思考,谁该为这些损失买单?我们未来遇到同样的问题怎么办?

对于白帽子来说,我们习惯于分解问题,同一个问题,我们可以在不同层面解决,可以通过良好的代码规范去保证(事实上所有的安全问题都能这么修复,只是需要付出的成本过于巨大),但如果PHP在源头修补了这个问题,才真正是善莫大焉。

 

BTW:is_a()函数的问题已经申报了CVE,如果不出意外security@php.net 也会接受这个问题,所以它已经是一个既成事实的漏洞了。

 from:http://hi.baidu.com/aullik5/blog/item/d4b8c81270601c3fdd54013e.html

发表评论

电子邮件地址不会被公开。

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>