今天看了bhst的這篇文章
了解了寬字元注入的一些東西
1. php 使用 php_escape_shell_cmd這個函式來轉義命令列字串時是作為單位元組處理的
2. 而當作業系統設定了gbk、euc-kr、sjis等寬位元組字符集時候，將這些命令列字串傳遞給mysql處理時是作為多位元組處理的
例如這裡：
http://localhost/gbk.php?username=%df%27 //多位元組編碼
%df%27=�』 //看，出單引號了，後面就可以構造了
sql語句類似這樣: select * from demo where username = 『�』 or 1#』 limit 1
這樣就可以注入啦
在php的處理過程中，它是單位元組處理的，它只把輸入當作乙個位元組流，而在linux設定了gbk字符集的時候，它的處理是雙位元組 的，大家的理解很明顯地不一致。我們查下gbk的字符集範圍為8140-fefe，首位元組在 81-fe 之間，尾位元組在 40-fe 之間，而乙個非常重要的字元\的編碼為5c，
結果就是：
神馬php自帶的addslashes，mysql_escape_string，
還有php.ini的magic_quotes_gpc神馬的，都無法過濾寬位元組搞出來的單引號，注入就來了
現在修補辦法就是設定設定客戶端的字符集為二進位制，
類似這樣：
1. mysql_query(「set character set 『gbk'」, $conn); //不安全的
2. mysql_query(「set character_set_connection=gbk, character_set_results=gbk, character_set_client=binary」, $conn); //安全的
當然，這樣還不能高枕無憂，還需注意，在下面的使用中，不要將使用者輸入的東西隨便轉換編碼，
因為一旦轉換，寬字元就又來了，上面寫的二進位制可只有gbk，你要是轉成utf-8，那寬字元不是又來了麼。
特別記錄下，自己以後寫**神馬的要注意下，假如要挖洞，也要注意，那個ecshop 2.6.x/2.7.x gbk版本的漏洞不就是這樣的嗎。
mysql 寬位元組注入 SQL注入之寬位元組注入
簡介 寬位元組注入是相對於單位元組注入而言的。單位元組注入就是大家平時的直接在帶有引數id的url後面 追回sql語句進行注入。比如 1 1 1 2 這個經典的判斷目標是否存在注入的例子就是單位元組注入。理論上說，只要資料庫連線 設定了gbk編碼，或者是預設編碼就 是gbk，那現在的程式裡到處都是注...
寬位元組注入
大家都知道 df 被php轉義 開啟gpc 用addslashes函式，或者icov等 單引號被加上反斜槓 變成了 df 其中 的十六進製制是 5c 那麼現在 df df 5c 27，如果程式的預設字符集是gbk等寬位元組字符集，則mysql用gbk的編碼時，會認為 df 5c 是乙個寬字元，也就是...
寬位元組注入
在使用php連線mysql的時候，當設定 set character set client gbk 時會導致乙個編碼轉換的問題，也就是我們熟悉的寬位元組注入，當存在寬位元組注入的時候，注入引數裡帶入 df 27，即可把 5c 吃掉，舉個例子。當提交 1 1 23 時，mysql的執行的sql語句為 ...