PHP 安全设置 %5c magic_quotes_gpc GBK

Tagged Under : , ,

安全问题。

今天看到一个朋友的blog上,写到PHP的安全设置,应该开启magic_quotes_gpc,避免SQL注入等。

可是,我在用Symfony开发时,文档上说应该关闭php.ini的magic_quotes_gpc,以前我不知道为什么,今天突然有些明白了。

这个设置,只能起到非常有限的安全作用,却有可能带来更严重的问题。

PHP的放置SQL注入,很多网站或教程上,都写着用addslashes或mysql_escape_string来过滤,或者用自动的magic_quote。这些函数的作用,就是查询字符串中的单引号、双引号和斜线”\”,在这些字符前面插入一个斜线”\”。

如果遇到了”頫運鳿黒靄錦鳿黒靄錦”这样的字符,而你的数据库、网页又是GBK编码的话,上面的3种过滤函数,都会给你带来麻烦,因为这些字符的第二个字节的编码,是%5c,恰好是”\”对应的编码。

原本是2个字节的汉字,被这些函数变成了3个字节,最后的2个字节是连续的”\”,而这第3个”\”会把后续的引号转义,因此SQL语句就会出错,导致更新无法执行。

安全建议:

  1. 设置php.ini,默认关闭magic_quotes_gpc
  2. 使用mysql_real_escape_string对字符串变量进行转义,注意,转义前判断magic_quotes_gpc是否已开启
  3. 使用utf-8编码,可以有效避免此类问题

PHP 文件下载 IE 无法打开页面

Tagged Under : , ,

IE 又有一个弱得不行的问题让我发现!

有个项目,要限制文件的下载权限,只有注册用户才可以下载,用户登录后,点击下载链接,弹出保存附件的提示。

我用 PHP 写了一个下载类,支持断点续传的。

今天发现一个问题,在 IE 7 下,点击链接,可以弹出对话框,提示 “打开”、”保存” 和 “取消”,点击打开没问题,点击保存,却马上弹出错误提示 “该页面无法打开”!

这时可以注意到一个细节,弹出保存对话框的时候,正常情况下窗口左边会根据文件类型显示图标,而此时却是一个没有类型的默认图标。

我怀疑是 PHP 在设置 Http Header 的时候有问题,仔细检查了每一项,逐项注释,问题依旧。

可是同样的链接,在 Firefox、Opera 和 Safari 下都没问题,打开或保存都正常。

后来去网上搜了好多文件下载的 header 设置,发现我少了 2 个属性:

Expires 和 Cache-Control,我想起来我以前写过一个 Case,说要加 Cache-Control,否则用IE 打开文件会提示 “文档已损坏”:

http://www.leakon.com/archives/76

这提醒了我,我应该加上 Cache-Control 的。

果然,加上下面这 2 行,问题就完全解决:
header(’Expires: 0′);
header(’Cache-Control: must-revalidate, post-check=0, pre-check=0′);

全部代码请见我的 GoogleCode:

http://leakon.googlecode.com/svn/trunk/leakon/php/iplimit/smart_download.php

这是支持短点续传的哦,很好用。

使用很简单,用文件绝对路径 new 一个对象,然后调用 $obj->download() 就可以啦。

当然,还可以通过参数,配置文件名和文件类型。

大伙儿看看吧,这是我给互联网的贡献~~

虚拟主机 SSH

问题由来:

我买了美国的虚拟主机,机器性能很好,空间巨大(150G) ,唯一的也是最大的问题,就是访问速度慢。

其实服务器本身至少能保证3M的带宽,我用其他服务器,单线程wget美国主机的文件,都可以稳定地保持在300K/s以上。

但用浏览器访问,由于需要发起多次tcp连接,而每次连接只传很小的几k文件就立即断掉,所以很慢。

最让我抓狂的就是,我上传一个软件包,总大小也就4、5M,但文件数量特别多,至少有几百甚至上千,传这么一个文件夹,没有2小时根本完不了。

我就想,如果虚拟主机有命令行,可以执行压缩或解压命令就好了。

传单个文件,再慢,也能保证每秒50K,像这样几M的文件,几分钟就可以搞定。

但如何解压呢?

答案就是:web版的命令行工具。

最简单的,就是system或exec函数,可以像SSH客户端一样,执行我们想要的命令。

注意,有些虚拟主机限制执行system和exec这两个函数,但我做了测试,证明是有其他方法的,一会儿再说这个方法是什么。

请您看到这个方法后,不要大肆宣传,或利用这个方法做一些危害主机安全的操作。如果这个方法也被禁用了,那以后就再也没有类似的方法了。

有了web的ssh,我们该怎么用呢?

1、首先要有清晰的unix文件的路径知识,知道什么是绝对路径,什么是相对路径,如何引用一个路径,等等。因为web版ssh只能方便地在当前一个目录下操作,稍有不慎,就可能造成无法挽回的后果。

2、学会使用ls、df、du、cp、mv、tar、zip等常用命令。使用web版ssh的出发点,就是希望以后在上传或下载文件时,可以预先打包,然后只传一个文件,这样可以大大减少传输时间的浪费。因此,列出目录、复制、移动、压缩和解压,就是必备的命令工具。

3、web版ssh还有一个功能,就是可以执行命令行的MySQL!!!最近我刚试着迁移discuz论坛,俗称论坛搬家,就是把论坛从A服务器迁移(搬家)到B服务器,重要的过程就是dump数据库,再import。而传统的工具,只有phpmyadmin,导出sql文件到还容易,但导入到另一个服务器,尤其是导入到另一个虚拟主机的时候,会受B主机的上传文件大小限制,大文件没法导入。还有,就是我遇到的乱码问题,由于B主机的大小限制只有2M,我的sql有5M,没办法,只能先压缩。import的时候,没有出错,但是导完发现都是乱码。A服务器是utf8,B是gbk。import的时候,本来import时选择了utf8编码的,但貌似对zip压缩的sql文件无效,最终是按gbk编码导入utf8的sql文件,这必然是乱码啊,结果就是论坛变成“蝌蚪文”。逼得我没办法了,只能开发一个web版ssh工具,最后用 mysql –default-character-set=utf8 -uleakon -pleakon leakon < leakon.sql 这个命令行才成功导入。这回,导入过程快多了,瞬间完成,不必再等着phpmyadmin上传本地sql文件。这一切,多亏了我的ssh工具,也就是本为的主角:web_shell。

按说这不叫ssh,只是一个web的命令行转发函数,但为了大家搜索虚拟主机ssh的时候能方便一些,就故意写了好多ssh。

大家可以看看国外的虚拟主机,大部分都支持ssh,而且……

唉,我都不想重复这些了,国外主机的优势,真不是国内idc服务商们可以比的。国内用最烂的服务、最烂的技术、最烂的界面来提供的虚拟主机,价格却是国外的好几倍甚至几十倍。价格我真不想再说了,反正最贵的都比国内最便宜的便宜好多好多,而且服务好得更多。

跑题了,回来说我的web_shell。

这是我简单开发的一个辅助工具,专门解决我上文提到的各种问题,加了一个简单安全验证,文件放在服务上,别人无法使用,只有你自己能用。

源码在我的GoogleCode里可以找到,地址是:

http://leakon.googlecode.com/svn/trunk/leakon/php/web_shell/web_zip.php

现在充其量是alpha 0.0.0.1版,里面还有一大堆debug的注释,本来还想加入一些新功能,但没那么多时间,先解决眼前的问题吧。

使用的时候,需要自己写一个web_inc.php,里面只要定义一个AUTH_KEY就可以了,这是你的密钥,只有知道密钥的人才可以使用这个web_shell。

默认的密钥,我是用一个字符串加当天日期的md5写的,如何快速计算一个字符串的md5呢?我早就写了一个工具,也许大家都没注意过,我就再发一次吧:

http://code.leakon.com/php/tools/

可以做一些简单的编码、解码计算,很好用哦。

源码也在googlecode里,大家自己找吧。

盼望得到您的指点或回复,谢谢!

另,php本身还有一个popen,也可以执行命令,一般的虚拟主机都没禁用,还是那句话,请慎用,要是用烂了,以后也就没得用了。

PHP 函数调用的开销

处理大量数据,每个关键词有5000条数据,一共有50万个关键词。

要对每个关键词的每条数据进行加权处理。

写了一个加权函数,作为一个类的静态方法。

遍历这50万个关键词的数据,结果非常慢。

考虑问题原因,尝试把加权函数的逻辑拆出来,放到大循环中。

写了测试代码,结果性能提升非常明显。

调用类的静态方法,程序性能是 156 次/秒,而拆出逻辑,直接运行,性能是 625 次/秒!

速度是原来的 4  倍多!

addslashes() Versus mysql_real_escape_string()

关于 addslashes() 和 mysql_real_escape_string() 两个函数,已经有过很多争论了。

在 PHP 过滤 SQL 注入时,通常都会使用  addslashes() 函数,但这并不保险,尤其是数据库编码是 GBK 时,类似于 %5c(\) 和 %27(’) 等字符时,不能得到预期的正确过滤。

我在使用  mysql_real_escape_string() ,数据库是 UTF-8 编码时,也是不能正常过滤,以 %5c 结尾的汉字,在做完转义后,效果仍然和 addslashes() 的结果一样。但同样的代码,拿到使用 GBK 编码编译的 MySQL 环境下就没问题。

我还没有搞明白到底问题出在哪里,最近会一直 focus 在这上面。

今天发现一个老外写的 Blog,分析得比较深入,尽管已经是 2 年前发表的了。

http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

分析得比较透彻,有很多人写了回复,仔细看看每个人的反馈,也能受益匪浅。

PHP 性能优化 二进制转换 pack()

今天搞一个数据存储程序,需要把数据转换成二进制存储。

在转换过程中,发现效率很低,不能满足需要。

经过反复测试和修改,总结了一些经验。

写在我的 Wiki 里了,Wiki 里贴代码比较方便,也顺便在这里推广一下我的Wiki

<<Leakon’s Wiki>>

性能优化的Wiki地址:http://wiki.leakon.com/PerformancePack

编码检查 UTF-8 浏览器编码

编码问题一直是做网站开发的工程师们很头疼的事,如果你希望自己的网站能够被更多不同语言环境的人浏览和使用,那就一定要解决好编码的问题。

我的经验是,从HTML页面的编码,到PHP程序文件的编码,到数据库的设计以及与PHP之间连接的编码,全部使用UTF-8,这样就能保证你的页面不会出现乱码。

不要总是觉得,你的网站是给中国人用的,不给其他国家的人使用。如果你的中国用户希望保存一些日文、韩文等亚洲文字, 你也没有理由拒绝吧?

还是在一开始就解决好编码的问题为好,做网站,免不了这一步,今天不做,以后迟早要还的。

如果你认为我说的毫无道理,那我给大家引用一篇W3C组织的官方说明吧:

http://www.w3.org/International/questions/qa-forms-utf-8.en.php

注意回答部分的第一句:The best way to deal with encoding issues in (X)HTML forms is to serve all your pages in UTF-8.

用UTF-8吧,肯定没错的,你可以避免很多很多问题。

不过,就算页面使用了UTF-8,也还是会遇到一个问题:

浏览器接收编码的转换问题。

就这个问题的说明,我做了一个测试页面,可以在我的Google SVN下载:

http://leakon.googlecode.com/svn/trunk/leakon/php/detect_utf8/

在浏览器里打开test.php页面即可。

这个页面是UTF-8编码的,如果你不是用SVN软件CheckOut而是直接复制的源码,请记得要把test.php这个文件保存成UTF-8格式。

这个页面有一个Form表单,你可以在输入框内输入中文,然后看地址栏里word字段的值,一个汉字对应3个%,因为UTF-8是变长编码的,针对不同的文字,%的数量是1-4个。

如果你熟悉GBK编码的页面,应该注意到每个汉字对应2个%,因为汉字都是双字节编码的。

这个时候,如果你足够细心,应该可以发现一个冲突的问题。

如果,我在浏览器的地址栏的word字段后面直接输入汉字,得到的是什么结果呢?给大家一个提示,这里最好使用Firefox浏览器,如果你在地址栏输入中文,Firefox会按照GBK的编码方式,按双字节编码,也就是一个汉字对应2个%。

可是你的页面默认是接收UTF-8编码的字符的,给你一个GBK编码,你会解析成乱码。

很多网站存在这个问题,包括Google和Yahoo。 他们只对各自的中文网站就解决了这个问题,英文的和日文的都没有处理。下面我们逐一测试一下:

我们给一个测试用例,中文:百度;GBK:%B0%D9%B6%C8;UTF-8:%E7%99%BE%E5%BA%A6。

看到了吧,GBK是4个%,UTF-8是6个%。

  1. http://www.google.cn/search?hl=zh-CN&q=%E7%99%BE%E5%BA%A6&btnG=Google+%E6%90%9C%E7%B4%A2&meta=
  2. http://www.google.cn/search?hl=zh-CN&q=%B0%D9%B6%C8&btnG=Google+%E6%90%9C%E7%B4%A2&meta=
  3. http://yahoo.cn/s?p=%E7%99%BE%E5%BA%A6&v=web
  4. http://yahoo.cn/s?p=%B0%D9%B6%C8&v=web
  5. http://www.google.com/search?hl=en&q=%E7%99%BE%E5%BA%A6&btnG=Google+Search
  6. http://www.google.com/search?hl=en&q=%B0%D9%B6%C8&btnG=Google+Search
  7. http://search.yahoo.com/search?p=%E7%99%BE%E5%BA%A6&fr=yfp-t-501&toggle=1&cop=mss&ei=UTF-8&vc=&fp_ip=CN
  8. http://search.yahoo.com/search?p=%B0%D9%B6%C8&fr=yfp-t-501&toggle=1&cop=mss&ei=UTF-8&vc=&fp_ip=CN
  9. http://www.google.co.jp/search?hl=ja&newwindow=1&q=%E7%99%BE%E5%BA%A6&btnG=%E6%A4%9C%E7%B4%A2&lr=
  10. http://www.google.co.jp/search?hl=ja&newwindow=1&q=%B0%D9%B6%C8&btnG=%E6%A4%9C%E7%B4%A2&lr=
  11. http://search.yahoo.co.jp/search?p=%E7%99%BE%E5%BA%A6&ei=UTF-8&fr=sfp_as&x=wrt
  12. http://search.yahoo.co.jp/search?ei=UTF-8&fr=sfp_as&p=%B0%D9%B6%C8&meta=vc%3D

以上是对Google和Yahoo两大搜索引擎的中文、英文、日文网站进行UTF-8、GBK编码的访问。

可以看到,2家公司只对中文网站做了编码检查,发现不是UTF-8就对关键词进行编码转换,得到了正确的结果,英文和日文都没有处理,给GBK编码时得到的是乱码。

他们就忽略了英文和日文用户搜索中文的需求。

其实,这个问题不是不可以解决的,中文网站都做到了,其他语言的怎么就不行呢?

这个不讨论了,还是说说怎么检查UTF-8编码吧。

其实就是一段正则表达式:

$regex    = '/^('
.
'[\x09\x0A\x0D\x20-\x7E]|'        # ASCII
.
'[\xC2-\xDF][\x80-\xBF]|'        # non-overlong 2-byte
.
'\xE0[\xA0-\xBF][\x80-\xBF]|'        # excluding overlongs
.
'[\xE1-\xEC\xEE\xEF][\x80-\xBF]{2}|'    # straight 3-byte
.
'\xED[\x80-\x9F][\x80-\xBF]|'        # excluding surrogates
.
'\xF0[\x90-\xBF][\x80-\xBF]{2}|'    # planes 1-3
.
'[\xF1-\xF3][\x80-\xBF]{3}|'        # planes 4-15
.
'\xF4[\x80-\x8F][\x80-\xBF]{2}'    # plane 16
.
')*\z/x';

大家从SVN里可以下载源码。

我封装了一个类,DetectUT8,用于检测和转换编码。

过程是这样的:如果检查到不是UTF-8编码,就进行GBK -> UTF-8的转换。因为在地址栏输入的非ASCII字符都会按照GBK编码。

转换函数会检查系统是否启用了 mbstring 函数库,如果没有,则改用 iconv 转换。

这里要注意一点,不要把UTF-8写成utf8,也不要写成其他格式,iconv 的检查比较严格。

如果内置了 mbstring 函数,还是用 mb_detect_encoding 比较保险,但经测试表明,用上面这段正则,编码检测的成功率和 mb_detect_encoding 没有差别。

还要重申一个问题,编码检测的可靠性不是 100%,但应用这种方法已经极大地改善了用户体验,建议大家都采用这种方式。

PHP 文件锁 flock 负载均衡

最近有个项目,采用单台前端服务器提供Web服务,程序需要实时访问后端服务器。后端一共有几十台服务器,但有压力限制,单台负载不能过高,必须做负载均衡。

最简单的方式是用随机数,前端来请求的时候,随机挑选一台后端服务器,但这并不能保证压力平均分布,很有可能在某一段时间内请求都落到同一台服务器上,很容易导致这台服务器停止服务。

后来想到用文件锁的方式,来标记访问计数,顺序访问后端的每一台服务器,让每一台服务器一个周期只被访问一次。

在进行了多次功能测试和压力测试后,验证了这种想法的可行性,然后写了一个IDService类,封装了整个过程。

我在Google提供的SVN服务器上保存了源码,大家可以在

http://leakon.googlecode.com/svn/trunk/leakon/php/flock/flock.php

这个地址看到源码,或者用SVN工具CheckOut到本地。

核心过程,就是初始化的时候给一个ID范围,默认是从0开始,如果你的server_count是32,那么调用getId()方法的时候,我会顺序给你31至0这32个ID,采用文件锁就是考虑到并发请求之间彼此独立,一个进程读数据文件的时候要加独占锁,解锁前,其他进程无法读取数据文件。

ID分配给你了,每个ID对应哪个服务器,就是你自己做映射的事了,保证了这个模块的无关性和独立性,和其他所有模块保持无耦合。

这是在PHP5的环境下写的,const 定义了3个类常量:

LINE_FEED 是换行符,Windows 下是 \r\n,Linux 下是 \n,只是为了方便测试的时候实时查看数据,可以是任意字符,只要不是数字就OK;

MAX_LOAD 是计数器的最大值,计数器都是从0开始,如果有任何一个ID达到了最大值,则所有ID计数器全部归零,开始新的一轮计数,其实这个设置只要大于0就可以,最好不要太大,因为存储数字也是要占用存储空间的,越小,id_data_file的尺寸就越小,硬盘读取就越快;

DATA_BLOCK 是设置一次读文件的数据大小,硬盘的一个文件至少要占一个簇,一般文件系统一个簇是4K,这个取值要跟ID的总量有关系,如果你的LINE_FEED是\n,MAX_LOAD是99(采用文本方式存储,2字节),那么一个ID占用3个字节,如果你有100个ID,那么数据文件占用空间就是300Byue,因此DATA_BLOCK设置为300是最佳值,需要注意,如果ID范围变大,需要同步更改此值,因此我默认设置了2048字节,小于硬盘的一个簇,相对于300字节来说没有性能损失,因为都在一个簇内,数据存储是连续的,硬盘只需一次寻道和一次读写。

源码里有使用说明,很简单,在实例化对象的时候指定ID范围和数据文件位置即可。

已经经过测试,给一些压力测试数据吧:

在AMD3000+和7200转80G硬盘的台式机环境,可以提供到 1300+次/秒 的速度,此时磁盘IO是瓶颈;
换上Linux服务器,具体配置不太清楚,反正是SCSI硬盘,100多G,只是开发用机,性能并不高,但可以提供 5000+次/秒 的速度。

综合2中环境的测试数据,以目前前端服务器的最高负载(最高也就 200+次/秒),以及项目的实际负载,此代码性能足够满足需要。

PHP require 绝对路径 autoload

在写PHP程序时,如果文件比较多,目录也比较多,有很多require_once的情况。

如果程序的入口不唯一,并且分布在不同的目录,必须require绝对路径,如果是相对路径,PHP会把入口文件的路径作为基本路径,require里的相对路径都是相对于入口文件的。

这样带来最大的问题就是自己部署的程序,给别人提供接口时,别人根本无法使用!

所以要用绝对路径。

做法就是选一个require的入口文件,大家都要包含这个文件,这个文件的开头加上这么一句:

<?php define("PROJECT_BASE_PATH", realpath(dirname(__FILE__) . "/../"));

这个时候PROJECT_BASE_PATH就是从根开始的绝对路径了。

后续的所有require文件,都用这个宏定义去拼接,例如:

<?php require_once(PROJECT_BASE_PATH .'lib/mysql.lib.php');

就绝对保证不会再出错!

当然,如果你是PHP5的环境,推荐使用__autoload函数,把所有功能都封装到类中,然后在需要的时候自动调用,避免到处require。

PHP 性能 安全 缺点

推荐资源一:a howto on optimizing php
http://phplens.com/lens/php-book/optimizing-debugging-php.php
总揽全局方能运筹帷幄决胜千里之外。这是一篇非常全面的php性能优化指南,高屋建瓴,教你全面均衡的优化你的应用。系统的介绍了LAMP架构下系统优化的各个层次。虽然两年半没有更新了,仍不失为经典的php优化扛鼎之作。

推荐资源二:php benckmark tests
http://www.php.lt/benchmark/phpbench.php
细节决定成败。这个简洁却不失细致的基准测试结果在“代码行”级别上教你如何编写高性能的php程序。尤其值得注意的是,和“同样的任务,面向过程的实现方式比面向对象快数倍”这个论调一样,php社区长期流传单引号速度远远快于双引号的言论,如今,时过境迁,这些经验是否还有效呢?我的建议是,相信你自己的判断,而不是道听途说。作决定之前,对你不了解的技术和架构做个垂直切片,而不是等到业务逻辑全部实现了才发现严重的性能问题。avoid surprises.

推荐资源三:PHP有什么缺点
http://www.nirvanastudio.org/php/php-in-contrast-to-perl.html
知己知彼,百战不殆。衡量一个人是否足够熟悉php的标准之一就是看他了解多少php的缺点,这篇文章罗列了PHP的很多不足之处,其中有很多地方都说的很中肯。了解了php的缺点,相信你能更好的驾驭它,用其可用之处。不过,也别走极端,任何技术都不是完美的,严谨的必然罗嗦(比如ADA),灵活的必然晦涩(比如Haskell),强大的必然难以驾驭(比如汇编),与其把时髦的技术挂在嘴边,不如把过时的技术放在心里。用好自己最熟悉的就是成功。

推荐资源四:《Essential PHP Security》http://project.5acity.com.cn/documents/essential_php_security.chm
一本PHP安全的电子书。软件工程有个很重要的原则就是防御式编程,遵守这个原则能让你生产安全健壮的产品。哦,顺便说个放之四海而皆准的道理:不要相信任何来自外部的数据。2004年的时候,我在linux下面用lumaqq把我的qq昵称修改为空了(不是空格,而是空白,什么都没有)。原因就是qq只在客户端验证了昵称是否为空,服务端却没有验证。

Google

Google
LAMP-Linux-redhat LAMP-Apache LAMP-MySQL LAMP-Php Leakon-Wiki Leakon-BBS XueBaoBao Xyoyou