大家都知道,addslashes是过滤垃圾信息的函数,如果你的PHP环境打开了魔法函数,那么addslashes这个函数将自动运行对用户提交的信 息进行过滤。但是addslashes函数在进行转义的时候,只对二进制字符串操作二不考虑字符集,结果产生BUG和漏洞。关于漏洞的产生,大家可以去百 度搜索《PHP字符编码绕过漏洞总结》,注入我不细说了,主要说说BUG。
首先要说明的是,此BUG只会在GBK字符集下会产生,GB2312无影响。我们来看GBK字符集的编码范围。
我们知道,addslashes函数一共要转义四个字符:' " \ NULL。NULL是字符串,不会产生问题,单引号 ' 和双引号 " 的ASCII码分别是27和22,不在GBK字符集的范围内,所以也不会产生问题。
而 \ 的ASCII码是5C,在GBK扩充集的低位范围内,同时addslashes函数在运行是后不会考虑字符集,这样BUG就产生了。以5C结尾的繁体中文 字,例如“躙”(0xDC5C),在运行addslashes函数过滤的时候,5C会被替换成5C5C,也就是说0xDC5C会被替换成 0xDC5C5C,实际输出就是“躙\”。
同理,转义符剥离函数stripslashes也会出现BUG,造成乱码。
修正这个BUG的办法只有一个,就是自己写一个带有字符集效验的addslashes函数,实际函数如下:
在实际使用中,如果系统开启了魔法函数,那么先要用stripslashes对变量进行转义符剥离,然后在使用我们自己的gbk_addslashes进行转义。
经过测试,这种方法不但可以避免BUG产生,还可以避免注入漏洞的产生,因为此函数不会对不属于GBK的字符进行转移,因此0xbf27不会被转义为0xbf5c27,大家尽管测试,我包售后服务。:)
显 然,这种办法应用麻烦,而且相对系统addslashes函数来说,效率会降低。但是这是我唯一想到的GBK字符集BUG的解决办法。其实我还是建议大家 应该放弃传统编程习惯,开始适应UTF-8编程。毕竟UTF-8是通用字符集,很多GBK下的BUG不会在UTF-8上产生。
大家有啥更好的解决办法或者异议欢迎讨论。
了解这些字:字的意思 符的意思 集的意思 下的意思 函的意思 数的意思 的的意思 注的意思