GBK字符集下addslashes函数的注入漏洞及BUG的解决办法

大家都知道，addslashes是过滤垃圾信息的函数，如果你的PHP环境打开了魔法函数，那么addslashes这个函数将自动运行对用户提交的信 息进行过滤。但是addslashes函数在进行转义的时候，只对二进制字符串操作二不考虑字符集，结果产生BUG和漏洞。关于漏洞的产生，大家可以去百 度搜索《PHP字符编码绕过漏洞总结》，注入我不细说了，主要说说BUG。

首先要说明的是，此BUG只会在GBK字符集下会产生，GB2312无影响。我们来看GBK字符集的编码范围。

 

引用

分区　　　　　　　　　　　　高位　　　低位
————————————————————————
●GBK/1:GB2312非汉字符号　: A1~A9 || A1~FE
●GBK/2:GB2312汉字　　　　: B0~F7 || A1~FE
●GBK/3:扩充汉字　　　　　 : 81~A0 || 40~FE
●GBK/4:扩充汉字　　　　　 : AA~FE || 40~A0
●GBK/5:扩充非汉字　　　　 : A8~A9 || 40~A0

我们知道，addslashes函数一共要转义四个字符：' " \ NULL。NULL是字符串，不会产生问题，单引号 ' 和双引号 " 的ASCII码分别是27和22，不在GBK字符集的范围内，所以也不会产生问题。

而 \ 的ASCII码是5C，在GBK扩充集的低位范围内，同时addslashes函数在运行是后不会考虑字符集，这样BUG就产生了。以5C结尾的繁体中文 字，例如“躙”（0xDC5C），在运行addslashes函数过滤的时候，5C会被替换成5C5C，也就是说0xDC5C会被替换成 0xDC5C5C，实际输出就是“躙\”。

同理，转义符剥离函数stripslashes也会出现BUG，造成乱码。

修正这个BUG的办法只有一个，就是自己写一个带有字符集效验的addslashes函数，实际函数如下：

 

引用

// 特殊字符转义函数
function gbk_addslashes($text) {
for ( ; ; ) {
$i = mb_strpos($text, chr(92), 0, "GBK");
if ($i === false) break;
$T = mb_substr($text, 0, $i, "GBK") . chr(92) . chr(92);
$text = substr($text, strlen($T) - 1);
$OK .= $T;
}
$text = $OK . $text;
$text = str_replace(chr(39), chr(92) . chr(39), $text);
$text = str_replace(chr(34), chr(92) . chr(34), $text);
return $text;
}

 

引用

// 转义符剥离函数
function gbk_stripslashes($text) {
$text = str_replace(chr(92) . chr(34), chr(34), $text);
$text = str_replace(chr(92) . chr(39), chr(39), $text);
for ( ; ; ) {
$i = mb_strpos($text, chr(92) . chr(92), 0, "GBK");
if ($i === false) break;
$T = mb_substr($text, 0, $i, "GBK") . chr(92);
$text = substr($text, strlen($T) + 1);
$OK .= $T;
}
$text = $OK . $text;
return $text;
}

在实际使用中，如果系统开启了魔法函数，那么先要用stripslashes对变量进行转义符剥离，然后在使用我们自己的gbk_addslashes进行转义。

经过测试，这种方法不但可以避免BUG产生，还可以避免注入漏洞的产生，因为此函数不会对不属于GBK的字符进行转移，因此0xbf27不会被转义为0xbf5c27，大家尽管测试，我包售后服务。：）

显 然，这种办法应用麻烦，而且相对系统addslashes函数来说，效率会降低。但是这是我唯一想到的GBK字符集BUG的解决办法。其实我还是建议大家 应该放弃传统编程习惯，开始适应UTF-8编程。毕竟UTF-8是通用字符集，很多GBK下的BUG不会在UTF-8上产生。

大家有啥更好的解决办法或者异议欢迎讨论。

原文：http://www.c-dd.org/post/10/