PHP CGI 中 fix_pathinfo 引起的安全隐患
这两天网上开始疯传一个“nginx文件类型错误解析漏洞”,这个“漏洞”是这样的:
假设有如下的 URL:http://phpvim.net/foo.jpg,当访问 http://phpvim.net/foo.jpg/a.php 时,foo.jpg 将会被执行,如果 foo.jpg 是一个普通文件,那么 foo.jpg 的内容会被直接显示出来,但是如果把一段 php 代码保存为 foo.jpg,那么问题就来了,这段代码就会被直接执行。这对一个 Web 应用来说,所造成的后果无疑是毁灭性的。
关于这个问题,已有高手 laruence 做过详细的分析,这里再多啰嗦几句。
首先不管你是否有用到正则来解析 PATH_INFO,这个漏洞都是存在的。比如下面这个最基本的 nginx 配置:
漏洞同样会出现,如 laruence 所说,实际上这个漏洞和 nginx 真的没什么关系,nginx 只是个 Proxy,它只负责根据用户的配置文件,通过 fastcgi_param 指令将参数忠实地传递给 FastCGI Server,问题在于 FastCGI Server 如何处理 nginx 提供的参数?
比如访问下面这个 URL:
那么根据上面给出的配置,nginx 传递给 FastCGI 的 SCRIPT_FILENAME 的值为:
也就是 $_SERVER['ORIG_SCRIPT_FILENAME']。
当 php.ini 中 cgi.fix_pathinfo = 1 时,PHP CGI 以 / 为分隔符号从后向前依次检查如下路径:
直到找个某个存在的文件,如果这个文件是个非法的文件,so… 悲剧了~
PHP 会把这个文件当成 cgi 脚本执行,并赋值路径给 CGI 环境变量——SCRIPT_FILENAME,也就是 $_SERVER['SCRIPT_FILENAME'] 的值了。
在很多使用 php-fpm (<0.6) 的主机中也会出现这个问题,但新的 php-fpm 的已经关闭了 cgi.fix_pathinfo,如果你查看 phpinfo() 页面会发现这个选项已经不存在了,代码 ini_get(“cgi.fix_pathinfo”) 的返回值也是 “false”。
原因是似乎因为 APC 的一个 bug,当 cgi.fix_pathinfo 开启时,PATH_TRANSLATED 有可能是 NULL,从而引起内存异常,造成 php-fpm crash,所以 php-fpm 关闭这个选项。
前几天把工作平台从 Ubuntu 9.10 Karmic 更新到了 10.04 Lucid,由于 Lucid 官方源自带了 PHP5.3.2,以前使用的 dotdeb 的源就没法用了,一直很喜欢这个源的,不但提供了 PHP5.3 而且还有 php5-fpm 这个很实用的 fcgi 进程管理器,这个在官方源里面是没有的。强行上了 dotdeb 虽然也可以,不过必然有很多包会出现依赖问题,处理这些依赖关系是件很烦心的事情。哥啥都不怕,就怕麻烦~
对于 PHP 来说,php-fpm 还是最合适的,spawn-fcgi 这类东西就不用考虑了,我宁愿用 PHP5 内置的 FastCGI Server。
Read more…
在 cygwin 中编译 PHP 时遇到下面的问题:
解决方法:
重新运行 ./configure 后,问题解决。
XP 和早期的 Windows 中,你可以通过系统新增或者修改某些类型的文件图标,但是自 Vista 以后,这个功能就被 "Default Programs" 替代了,要修改图标只能依赖一些第三方软件。如果不想使用第三方软件,则可以通过修改注册表来手动更改文件的图标,以下以 PHP 文件为例:
按照配置文件,我的项目地址是:http://localhost/myproject/public,项目是部署在子目录 /myproject/public 里面的,如果你把 document_root 直接设置为 /myproject/public,使用 http://localhost 来访问,那么上述配置删除掉 index.php 前面的目录部分,也就是 rewrite ^/(.*)$ index.php last;
Nginx 不支持 Apache 的 .htaccess 文件,所以需要在 Nginx 配置文件中编写重写规则。Apache 的绝大部分 RewriteRule 命令都可以不做修改的放到 Nginx 中直接使用。你只要把 RewriteRule 改成 rewrite,[L] 改成 last 之类的就可以了,具体可以看一下 Nginx 的 Rewrite 文档。
http://wiki.nginx.org/NginxHttpRewriteModule
题外话,Zend Framework 越来越强大,越来越复杂了,很多追求“简洁”的 Coder 们都已经开始信誓旦旦的说要放弃 ZF 。有点搞笑,这就好像我在说:飞机太快了,价钱太贵了,不适合我,还是自行车好啊!有些人对待问题的看法极端又片面,就好像看电视剧的时候,也总是要把人分为好人和坏人一样,他们的想法很单纯——我不喜欢 ZF,因为臃肿、复杂,所以它是垃圾。
Nginx 是一个轻量级的高性能 Http WebServer,以事件驱动方式编写,因此相比 Apache 而言,Nginx 更加稳定、性能更好,而且配置简单,资源占用较低。以下是我在 Windows 7 安装中 Nginx 和 PHP5.3 的步骤。
安装 PHP5
首先,从 http://windows.php.net/download/ 下载最新的 PHP 5.3 Windows 版本,这里 PHP 以 FastCGI 模式运行,所以请下载 None Thead Safe 版本。
解压至 C:\php5,把压缩包中的 php.ini-recommended,更名为 php.ini,然后打开修改几个选项:
在 Akra’s DevNotes 看到的这篇文章,刚好最近两篇文章都是将乱码的,于是也搬过来了。
问题:
存储多字节字符到 MySQL,或者从 MySQL 中读取类似的数据,出现乱码。
解决方法:
在任何地方都使用 UTF-8 编码。
> 浏览器
或者使用一个 meta 标签来设置HTTP协议的响应头报文:
这行 HTML 代码会通知客户端浏览器,文件类型为 html,且使用了 utf-8 编码。
header()函数所发送的 HTTP,从优先级上面看,由于先一步被浏览器所接受,所以优先级更高(不知道可不可以这么说)。
Read more…
基本思路就是向数据库发送 SQL “SET NAMES UTF8″,可根据不同的情况来编写代码。
如:
这是早期的解决方法,其实并不推荐这么做,因为并不是所有页面都需要 SQL 查询,上述代码放在 bootstrap 中,在不需要 SQL 连接的页面中也会开启一次数据库连接并发送 SET NAMES UTF8 ,这就浪费了资源。
Read more…
Zend_Filter_Input 可以用来获得安全可靠的用户数据,简单的来说这个类就像一个黑盒,原始数据输入后,经过过滤器过滤,然后再由校验器校验,若通过了原先设定的过滤及校验规则,则最后输出可用的数据,否则给出详细的错误报告。
为了数据安全,比如转义一些特定字符,默认情况下 Zend_Filter_Input 会使用 HtmlEntities Filter 过滤所有的数据,然而不幸的是,这个 HtmlEntities 使用默认编码 ISO-8859-1,如果是中文等多字节语种,那么最后数据就会出现乱码,面目全非。
最近我在自己的项目中就遇到这个问题,其实解决方法很多,多写几行代码而已,但是因为乱码的问题由来已久,而且造成乱码的原因也非常多,找不到问题所在,那就恼火的很了,这里简单总结了一下。
Read more…
以前在使用 xdebug 的时候,偶有崩溃现象,但并不是太频繁,但是自从换用 Apache2.2 以后,Apache 崩溃的频率大幅增加,换用了不同的 PHP 和 xdebug 的版本都是一样,不停的崩溃,正常的开发根本无法保证。
后来无意中发现是 php5apache2_2.dll 的问题,因为我一直使用 module 模式安装 PHP5,所以不管 PHP5 和 xdebug 换到什么版本,都没有意义,昨天将 php5 换到 CGI 模式后,配合 xdebug 一直使用到现在,Apache2 再也没有崩溃过。