第32关 宽字节注入

查看一下本关的源代码：

function check_addslashes($string)  
// 定义一个用于过滤特殊字符的函数，目的是转义可能用于注入的特殊符号
{$string = preg_replace('/'. preg_quote('\\') .'/', "\\\\\\", $string);           
// 转义反斜杠：将单个反斜杠替换为两个反斜杠（防止反斜杠被误用为转义符）$string = preg_replace('/\'/i', '\\\'', $string);                                
// 转义单引号：将单引号替换为“反斜杠+单引号”（防止单引号闭合SQL字符串）$string = preg_replace('/\"/', "\\\"", $string);                                 
// 转义双引号：将双引号替换为“反斜杠+双引号”（防止双引号闭合SQL字符串）     return $string; // 返回处理后的字符串
}

自定义了一个函数，过滤了单引号，双引号和反斜杠。这里输入的单引号被转义成反斜杠加单引号。

但是在源代码中写到本关使用GBK编码，GBK为双字节编码，一个汉字由两个字节组成。利用多字节字符编码特性，构造特殊字符，使原本被转义的字符在编码转换过程中逃逸出来，从而产生了宽字节注入攻击。

举例，%27 是单引号 ' 的URL编码。%bf 是一个特定的字节（十六进制为0xBF），它属于GBK编码的第一个字节范围，所以当它后面跟着一个字节（比如0x5C，即反斜杠）时，它们会组合成一个GBK字符。

漏洞触发过程：

1. 用户输入：%bf%27 （即0xBF 0x27）。

2. PHP的转义函数检测到单引号（0x27），于是在它前面加上反斜杠（0x5C）。所以进一步变成为：0xBF, 0x5C, 0x27。

3. 然后这个字符串被拼接到SQL语句中，SQL语句在数据库里执行时，数据库使用的是GBK编码，它会将两个字节看作一个汉字。其中0xBF和0x5C（反斜杠）组合在一起，被当作一个GBK字符（这个字符是“縗”，读cuī）。这样，0x27（单引号）就独立出来了，导致转义失效。

测试：

这里只输入一个单引号会被过滤，利用宽字节注入使单引号不被转义，则union查询成功。

 第33关 使用内置函数的宽字节注入

本关使用的是PHP内置的addslashes函数，它的作用是添加反斜杠进行转义。区别在于上一关是自定义函数，这一关是用内置函数，但都是宽字节注入，解法相同。