在注入時通常會使用單引號、雙引號等特殊字元。在應用中，通常為了安全，開發者會開啟php的magic_quotes_gpc，或者是addslashes、mysql_real_escape_string等函式對客戶端傳染到的引數沒有進行過濾，則注入的單引號或雙引號就會被「\」轉義，但是，如果伺服器端的資料庫使用的是gb2312、gbk、gb18030等寬位元組的編碼是，則依然會造成注入。
gbk————占用兩個位元組
ascii————占用乙個位元組
php中編碼為gbk，函式執行新增的是ascii編碼，mysql預設字符集是gbk等寬位元組字符集。
輸入%df和函式執行新增的%5c，被合併成%df%5c。由於gbk是兩位元組，這個%df%5c被mysql識別為gbk。導致本應的%df\變成%df%5c，%df%5c在gbk編碼中沒有對應，所以會被當成無效字元。
%df:會被php當中的addslashes函式轉義為「%df」,"\"即url裡的「%5c」,那麼也就是說，「%df」會被轉義成「%df%5c%27」倘若**的字符集是gbk，mysql使用的編碼也是gbk的話，就會認為「%df%5c%27」是乙個寬字元，就是「縗」
注入點：' order by 2%23
提交%df之後出現錯誤，由此可見存在寬位元組注入。
獲取資料庫名
' union select 1,databases()%23前面已經多次提到這部分內容，所以之後的不再贅述！
web滲透 33 寬位元組注入
寬位元組注入是相對於單位元組注入而言的，該注入跟html頁面編碼無關，寬位元組注入常見於mysql中，gb2312 gbk gb18030 big5 shift jis等這些都是常說的寬位元組，實際上只有兩位元組。寬位元組帶來的安全問題主要是吃ascii字元 一位元組 的現象，當 df 被php轉義...
SQL注入 寬位元組注入
php測試 物件導向寫法 id addslashes get id 獲取id並轉義預定義字元 id get id mysqli new mysqli localhost root root test 連線資料庫 指定資料庫 if mysqli connect errno else else 面向過程...
寬位元組注入
大家都知道 df 被php轉義 開啟gpc 用addslashes函式，或者icov等 單引號被加上反斜槓 變成了 df 其中 的十六進製制是 5c 那麼現在 df df 5c 27，如果程式的預設字符集是gbk等寬位元組字符集，則mysql用gbk的編碼時，會認為 df 5c 是乙個寬字元，也就是...