addslashes的安全问题

Submitted by 月黑风高 on 2008年08月31日 03:21:36. PHP

PHP代码

<?php
$a = "abc's";
//echo getHex(addslashes($a));
$a = getStr('bf27');
echo getHex(addslashes($a));
echo "";
echo getHex(strip27(addslashes($a)));
function getHex($a) {
$len = strlen($a);
for ($i = 0; $i < $len; $i++) {
$t .= dechex(ord($a[$i]));
}
return $t;
}
function getStr($a) {
$len = strlen($a);
for ($i = 0; $i < $len; $i += 2) {
$t .= chr(hexdec(substr($a, $i, 2)));
}
return $t;
}
//不一定正确的二次过滤
function strip27($str, $encoding = 'gbk') {
$len = strlen($str);
for ($i = 0; $i < $len; $i++) {
if (ord($str[$i]) > 127) {
$i++;
} else if ($str[$i] == chr(0x27)) {
$str[$i] = chr(0x20);
}
}
return $str;
}

http://www.cnblogs.com/Safe3/archive/2008/08/22/1274095.html
重装系统之后虚拟机起不了，直接在zs中测试，确实存在问题，
PHP处理字符还是以单字节为单位，所以PHP页面中如果不放中文，可以存成任何编码
addslashes在过滤的时候也是以字节进行过滤的，这就会破坏GBK的序列，逻辑上来说，
即使不注入，使用addslashes也会导致个别字符乱码。
如果数据库是gbk，插入数据库时，数据库0xbf5c当成一个字，这种情况不只在gbk其它多字节的数据库里也应该有问题

update:080901 晕，我一直有个误区，以为gbk的第二个字节是从0开始，BS，实际GBK的范围是在8140-FEFE，这样，0x27不在gbk的范围中，直接使用str_replace替换就OK，谢谢safe3前辈