一、环境

网上有自己找很快

二、如何通关

2.1解释

虚假预编译没有参数绑定的过程，真实预编译有参数绑定的过程

宽字节注入出现的本质就是因为数据库的编码与代码的编码不同，导致用户可以通过输入精心构造的数据通过编码转换吞掉转义字符。

在32关中它先过滤了我们的单引号和双引号之后又进行一个编码的转换转为gbk，之后我们才查询

gbk和utf-8的区别

gbk占两个字节，utf-8占三个字节

首先先测试一下

'?id=1

有没有一种可能我们的单引号被gbk转译为5c了，单引号被编码为27了 

那我尝试一下%aa和%df看看是什么情况

?id=1%aa'

?id=1%df'

好像都可以，页面有区别，有报错，很明显已经闭合了，我们第一次明显没有闭合

那到底怎么来的？？？

我们试着给后面加个联合查询看看 ,很明显注入成功了，已经绕过了

?id=-1%df' union select 1,2,3--+

那原理到底是什么呢？

gbk两个字节代表一个汉字，utf-8三个字节代表一个汉字 

?id=1'刚进去是?id=1\'被转译了一下，之后gbk编码把它转为了?id=1%5c%27,之后我们加了%df和%aa，然后就闭合了，那有没有可能%df%5c%27这三个可以组成一个汉字，假设转换为一个汉字中，那么代码变为?id=1中'那其实我们转译字符已经被吃掉了，那就已经逃逸出单引号了，在后面写我们代码自然就过了

那原理就很简单了：使用了错误的编码，那么宽字节注入就已经绕过了

三、防御

不适用虚拟预编译使用真实的预编译即可防御

四、这里有两篇文章真假预编译解释的很详细

预编译与sql注入 – fushulingのblog

奇安信攻防社区-SQL注入&预编译