关于昨日爆出的 Nginx + PHP CGI 漏洞的一点点补充

我第一次看到这个漏洞是在 Laruence 的博客。看完之后,我赶紧评估了一下我们正在开发的产品出现这个漏洞的可能性。还不错,在我们当前架构下,这个漏洞被成功利用的可能性为 0 …… 结果,今天在大嘴巴 cnbeta 看到了这篇很标题党的新闻《80后发现nginx 0day漏洞,上传图片可入侵100万服务器》。然后引用的出处是这里。 好了,我认为我提供的背景资料足够详细了。现在说说为什么我们的产品不会出现这个被利用的可能吧。 其实很简单,将资源文件和 php 脚本文件放在不同的域名下面。然后将资源文件(含产品自身的和用户贡献的)的访问限于只作文件传输,不作任何的脚本解析。 例如 PHP 脚本执行的主机名是 www.mikespook.com。而上传文件和图像、js、css 等放在 static.mikespook.com 主机名下。 其实,就是这么简单的一个隔离措施,就避免了出现这种上传并解析的漏洞。 即使想用同一个域名,通过对 nginx 的配置禁止资源文件目录下的文件被当作脚本解析也是很容易的。 这个故事教育我们:细节是基石,架构是王道!!! 另,根据来自高春辉的可靠消息,手机之家也不存在此问题……

关于 php 的 count 函数

今天一个同事在Q群上考大家关于 php 的 count 函数的一些东东,大意是 count(‘some string’) 会输出什么……印象中,以前跟谁讨论过这个。不过日子久远,已经有些模糊了。所以还是写下来,just4fun。 大部分实践者都知道 count(string) 输出的结果是 1,而不是有的人期望的 strlen(string)。如果输出 count(callback),会惊奇的发现结果也是 1。这是为什么呢?

脚本语言的配置文件

关于配置文件,在 PHP 的 Zend Framework 中我做过一些简单的关于性能的测试:http://www.mikespook.com/index.php/archives/36。将 ninnypro 的配置文件从 ini 修改为 xml ,并且声称能提高传说中的性能。 最近被调到另外一个在用 python 的组帮忙,阅读了他们的实现服务器端的 python 代码之,配置文件近二十余个,全是 xml 文件。为了使用着些配置文件,从 XMLFile 继承,实现了二十余个 Config 类。 这看起来似乎没什么问题。

[翻译]PHP的命名空间真这么糟糕么?

几年前(大约应该在02-03年之间,也就是php5刚出来那会)曾经跟朋友讨论过一次关于php的命名空间的问题。当时觉得,php要是能有命名空间,那是多完美的事情啊。 如今,php5.3已经包含了命名空间。但是似乎并没有当年的那种感慨了。大约是旧的系统要迁移,新的系统要重新设计,这个名字空间都有点鸡肋的感觉。看来还要习惯一下才好。 看到这篇文章,觉得说得是有点对的。也不长,就随手翻译出来。翻译后的感觉:作者 超级喜欢使用“However”。 能说明两个问题: php本身为什么是这样 php的名字空间为什么是这样 作者:Craig Buckler 原文:http://www.sitepoint.com/blogs/2009/08/13/are-php-namespaces-bad/

mb_ereg(i)_replace() 执行任意代码的漏洞

这个漏洞说大也大,说小也小。大是因为真得可以通过注入的方式让漏洞代码执行任意代码。小是因为产生漏洞的环境还是比较苛刻的。 来源于此:http://milw0rm.com/exploits/8641 当最后一个参数设置为“e”,也就是将替换的内容作为 PHP 代码执行的时候,漏洞就产生了。 例如: function hi80vul() {} $str = ‘\’, phpinfo(), \”; mb_ereg_replace(‘^(.*)$’, ‘hi80vul(\’\1\’)’, $str, ‘e’); 又例如: function hi80vul() {} $str = ‘\’, var_dump(get_loaded_extensions()), \”; mb_ereg_replace(‘^(.*)$’, ‘hi80vul(\’\1\’)’, $str, ‘e’); 如果有在代码中使用过 mb_ereg_replace 和 mb_eregi_replace,以及参数“e”,那就赶紧检查一下是否有这样的安全隐患吧。

广州PHP培训和我的一些想法

首先,在 google 做一个搜索,关键词“广州 PHP 培训”。大约有 1,230,000 项符合的结果。在百度上搜索相同的关键字,大约有 38,500 项符合的结果。 其中呢,“多迪”培训是占了大多数的,然后就是“慧的”培训。其实这两家都是老熟人了。

Zend Framework 1.8.0 带来的变化

曾经,我很羡慕 Django 等框架那完善的自动化工具。说实话,在 MVC 框架中不停的建立Controller、Action 是一件又枯燥,又麻烦的事情。而且,维护起来也颇费功夫。所以在 ninnypro 中我引入了一个 cli 工具,用于创建 Controller、Action 以及更新 ACL 的资源表。 现在,这些都将成为历史了。 Zend Framework 引入了 Zend_Tool 和 Zend_Application 两个包,用于自动化和快速集成。并且成熟的命令行工具 zf 也可以使用了。例如这里!! zf 将程序员的关注点聚焦到程序功能和细节的实现,更加的统一和方便。跟 ninnypro 的思路类似,以放弃灵活性为代价,换取约束性和开发速度。 如果我有精力,或许会在此基础上重新建构 ninnypro 吧。

PHP框架的繁荣是正确的发展方向吗?

这个其实是源于 javaeye 上的这个讨论:http://www.javaeye.com/post/886707。最开始吸引我的是在 rails 板块上诸多专业玩 java 和 ruby 的人是如何评价 php 以及 php 框架的。在讨论中发现有一些值得学习和借鉴的地方。所以推荐大家完整阅读这个帖子。从技术性、知识面和娱乐性来讲,都是质量很高的。 我就简单说一下我对于 php 框架繁荣的看法: