PHP代码审计之SQL注入-第二回

嗨喽，我知众君期待已久，今日特此再现美文一篇，来来，欢呼声在哪里？

OK，收。回归正传了啊，说起第一回的基本 SQL 注入，等等是谁在喊：第一回的sql注入已经分分钟搞定了。

那行，今日要说的是sql注入中的宽字节注入，帅哥美女们请收起大家的疑惑，坐好小板凳，听我细细说来：

首先，一定要明白何为宽字节，通俗点说： 一个汉字用 gbk 占两个字节，用utf8占三个字节，所谓宽字节注入就理解成利用字节不同导致的问题就ok了 。

接下来，我要为你们介绍几位大名鼎鼎的人物了，哈，他们分别是 addslashes、mysql_real_escape_string、mysql_escape_string、magic_quote_gpc ，这是啥？四大天王吗？

nonono，它们 为了防止 sql 注入，会将一些什么 单引号 了， 双引号 了那些对sql有影响的 特殊符号 进行实体转义，就是加了一个 斜杠 ，这些函数具体转移哪些符号，哥们们可以去搜一下，码字很辛苦，此处我就省了。

平白无故为什么要介绍他们呢，有没有发现，第一回说的那个基本sql注入已经被这四大屌丝（并非天王）轻松搞定了。

咱第一回的成功就这样被搞定了？来，看例子：

这代码大家很熟悉了，在第一回的代码基础上加了个addslashes函数，那么效果如何，请看：

我勒个去，那个单引号给我加了个斜杠，转义了。那接下来怎么搞？两个方法： 1，斜杠前加斜杠，相当于转义斜杠，单引号生效。2，去掉斜杠，单引号生效。

我去，好办法，当然实践前必须要明白个道理 ， 这个道理很重要，我通俗的说，大家多读几遍，否则原理就不好理解了。

其宽字节是利用mysql的特性，mysql它在用gbk 编码 的时候，它会认为两个字符是一个汉字，且前一个字符的 ascii 码要大于128。

不理解？不急，那我再多码点字来解释下，必须要明白ascii码为何要大于128，这个编码大于128会怎样，先看张图：

这是ascii表的最后一条数据，最后一个是127，也就是前127个都是字符，超过127怎么办，那不好意思，我就不能把你当字符了，那当什么，把你当成汉字。

还是刚才那个例子，这次我不输入单引号了，我输入了一个 %df%27 ，输入了个啥？别急，先看下代码：

注意我加的那个mysql_query(“set names ‘gbk'”);，它会设置字符为gbk，它是造成宽字节的始作俑者 。看下结果：

斜杠没了，这个单引号此时是生效的。为什么，结合刚才让大家多读几遍的那个原理来看：

首先，要明白，咱访问的url中经常都是一堆%什么的特殊字符，很多很长的网址，那都是url编码将字符转换的结果。其次%df的ascii的编码是大于128的，非要用%df吗，非也，只要ascii大于128即可。那么，就变成了%df\%27了，这时候mysql就把%27\当作汉字了，就是那个繁体字，而单引号就生效了，在url编码中%27是单引号。

那，宽字节是不是有概念了呢，相信兄弟们都懂了。

四大屌丝才说了一个addslashes函数，码字也码累了，看看时间也快下班了，在码一会，其它屌丝下回接着码。

此时此刻，相比很多人心中都有疑问了，我们写程序都是utf8啊，谁还用gbk，你的程序要是用的utf8编码，那这个宽字节注入可以忽略，要是gbk，嘿嘿，危险了。

其实宽字节注入很普遍，大家会发现很多cms系统都有两个版本，一个是gbk，一个是utf8，有的是为了照顾以前的用户，所以一直在用gbk，有的是专门就弄自己的gbk编码。所以，这个在各大cms中经常见。

当然，有攻便有防，至于防御，在咱们把所有的类型全部码完之后，再来个大大的总结。

那针对咱们今天说的这个addslashes函数怎么做审计呢？

ok，认真了，干货来了： 其实非常简单，项目全局搜索以下几个关键字：1，SET NAMES. 2,character_set_client=gbk. 3,mysql_set_chatset(‘gbk’). 从字面就知道，他们呢都是用来设置 字符编码 的。

来一条华丽的分割线：

最后，如果大家喜欢网络三毛，欢迎wx关注，不定期发表关于审计、攻防、安全、渗透方面的知识。