SQL注入最易懂系列教程

在上节我们讲了宽字节注入，宽字节注入主要是因为转译特殊字符时候，因为宽字节占用字符长度原因，构造语句从而消灭掉转译字符 \，从而导致宽字节注入。二次编码注入和宽字节注入非常相似。

一.关于编码的知识、

1.为什么要进行Url编码

我们都知道Http协议中参数的传输是"key=value"这种键值对形式的，如果要传多个参数就需要用“&”符号对键值对进行分割。如"name1=value1&name2=value2"，这样在服务端在收到这种字符串的时候，会用“&”分割出每一个参数，然后再用“=”来分割出参数值。

现在有这样一个问题，如果我的参数值中就包含=或&这种特殊字符的时候该怎么办。 比如说“name1=value1”,其中value1的值是“va&lu=e1”字符串，那么实际在传输过程中就会变成这样“name1=va&lu=e1”。我们的本意是就只有一个键值对，但是服务端会解析成两个键值对，这样就产生了奇异。

如何解决上述问题带来的歧义呢？解决的办法就是对参数进行URL编码

URL编码只是简单的在特殊字符的各个字节前加上%，例如，我们对上述会产生奇异的字符进行URL编码后结果：“name1=va%26lu%3D”，这样服务端会把紧跟在“%”后的字节当成普通的字节，就是不会把它当成各个参数或键值对的分隔符。

通常如果一样东西需要编码，说明这样东西并不适合传输。原因多种多样，如Size过大，包含隐私数据，对于Url来说，之所以要进行编码，是因为Url中有些字符会引起歧义。

2.URL编码

形式：“%”加上ASCII码（先将字符转换为两位ASCII码，再转为16进制），其中加号“+”在URL编码中和“%20”表示一样，均为空格。

当遇到非ASCII码表示的字符时，如中文，浏览器或通过编写URLEncode，根据UTF-8、GBK等编码16进制形式，进行转换。如“春”的UTF-8编码为E6 98 A5，因此其在支持UTF-8的情况下，URL编码为%E6%98%A5。值得注意的是采取不同的中文编码，会有不同的URL编码。

在URL传递到后台时，首先web容器会自动先对URL进行解析。容器解码时，会根据设置（如jsp中，会使用request.setCharacterEncoding("UTF-8")），采用UTF-8或GBK等其中一种编码进行解析。这时，程序无需自己再次解码，便可以获取参数（如使用request.getParameter(paramName)）。

但是，有时从客户端提交的URL无法确定是何种编码，如果服务器选择的编码方式不匹配，则会造成中文乱码。为了解决这个问题，便出现了二次URLEncode的方法。在客户端对URL进行两次URLEncode，这样类似上文提到的%E6%98%A5则会编码为%25e6%2598%25a5，为纯ASCII码。Web容器在接到URL后，自动解析一次，因为不管容器使用何种编码进行解析，都支持ASCII码，不会出错。然后在通过编写程序对容器解析后的参数进行解码，便可正确得到参数。在这里，客户端的第一次编码，以及服务端的第二次解码，均是由程序员自己设定的，是可控的，可知的。

二.urldecode()二次解码引发注入

PHP中常用防注入过滤函数如addslashes()、mysql_real_escape_string()、mysql_escape_string()或者使用魔术引号GPC开关来防止注入，原理都是给单引号（’）、双引号（”）、反斜杠（\）和NULL等特殊字符前面加上反斜杠来进行转义。

但是这些函数在遇到urldecode()函数时，就会因为二次解码引发注入。urldecode()函数是对已编码的URL进行解码。引发注入的原因其实很简单，PHP本身在处理提交的数据之前会进行一次解码，例如/test.php?id=1这个URL，我们构造字符串/test.php?id=1%2527，PHP第一次解码，%25解码成了%，于是url变成了/test.php?id=1%27；然后urldecode()函数又进行了一次解码，%27解码成了’，于是最终URL变成了/test.php?id=1’，单引号引发了注入。rawurldecode()也会产生同样的问题，因此这两个函数需要慎用

因为mysql_real_escape_string()是在urldecode()之前，所以并不能过滤由于urldecode()产生的单引号

举个例子：

普通的注入会被转译掉：

于是构造url编码引发注入

以后黑盒测试跑SQL注入可以在URL后面加上%2527，说不定就能碰到二次解码引发注入的情况。