谁来为漏洞买单？

 昨天介绍了一下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，如果不出意外[e-mail] 也会接受这个问题，所以它已经是一个既成事实的漏洞了。