概念

單字節字符集： 所有的字符都使用一個字節來表示，比如 ASCII 編碼。

多字節字符集： 在多字節字符集中，一部分字節用多個字節來表示，另一部分(可能沒有)用單個字節來表示。

兩位的多字節字符有一個前導字節和尾字節。 在某個多字節字符集內，前導字節位于某個特定范圍內，尾字節也一樣。

UTF-8 編碼： 是一種編碼的編碼方式(多字節編碼)，它可以使用1~4個字節表示一個符號，根據不同的符號而變化字節長度。

常見的寬字節： GB2312、GBK、GB18030、BIG5、Shift_JIS

GB2312 不存在寬字節注入，可以收集存在寬字節注入的編碼。

前提條件

簡單理解:數據庫編碼與PHP編碼設置為不同的兩個編碼那么就有可能產生寬字節注入

深入講解：要有寬字節注入漏洞，首先要滿足數據庫后端使用雙/多字節解析SQL語句，其次還要保證在該種字符集范圍中包含低字節位是 0x5C(01011100) 的字符，初步的測試結果 Big5 和 GBK 字符集都是有的， UTF-8 和 GB2312 沒有這種字符(也就不存在寬字節注入)。

SQL 執行原理

網上遇到一個能較好體現 SQL 語句的解析&執行過程的圖片，在這里：

假如這個網站有寬字節注入那么我們提交：

http://127.0.0.1/GBK?id=%df%27

這時,假如我們現在使用的是addslashes來過濾,那么就會發生如下的轉換過程

例子：

%df%27===(addslashes)===>%df%5c%27===(數據庫GBK)===>運'

SQL 在執行過程中，會分為如下幾個部分：

1.客戶端以某種字符生成SQL語句發送至服務器，這里“某種字符”其實是任意規定的，當 PHP 作為客戶端連接 MySQL 的時候，這個字符集就是 PHP 的默認編碼。

2.服務器接收到請求后會把客戶端編碼的字符串轉換成連接層編碼字符串(具體流程是先使用系統變量character_set_client 對 SQL語句進行解碼后會使用系統變量 character_set_connection 對解碼后的十六進制進行編碼)。

3.進行內部操作前，將請求按照如下規則轉化成內部操作字符集，如下：

3.1 使用字段 CHARACTER SET 設定值；

3.2 若上述值不存在，使用對應數據表的DEFAULT CHARACTER SET設定值；

3.3 若上述值不存在，則使用對應數據庫的DEFAULT CHARACTER SET設定值；

3.4 若上述值不存在，則使用character_set_server設定值。

4.執行完 SQL 語句之后，將執行結果按照 character_set_results 編碼進行輸出。

使用 SET NAMES 命令SET NAMES ‘gbk’或是 SET character_set_client =gbk，這樣配置會引發編碼轉換從而導致的注入漏洞。

SET NAMES ‘x’語句與這三個語句等價：

mysql>SET character_set_client =x;

mysql>SET character_set_results =x;

mysql>SET character_set_connection =x;

也就是說你設置了 SET NAMES ‘x’ 時就等于同時執行了上面的3條語句

總結

在使用UTF-8 對 SQL 語句進行解析時，若想發生注入，并不是在解析 MySQL 語句的階段，而是在客戶端提交到服務器之前就已經發生了 SQL 注入，所以這種注入并不是 UTF-8 編碼的鍋， 統一使用 UTF-8 編碼并且不要使用危險的函數 iconv 是一個比較安全的編碼方案。

如果由于歷史遺留原因一定要使用 GBK 的編碼(解析)方式可以采用 mysql_set_charset 配合 mysql_real_escape_string 轉義的方式進行防護。

在代碼審計的較多需要留意一下 類似 GBK 和 BIG5 這種的雙字節編碼，同時存在低字節位位可以是 %5C 的字符，如果使用這種存在這種字符的編碼對 SQL 語句進行解析，寬字節注入就離你不遠啦。

參考:

https://paper.tuisec.win/detail/80365c7a33e34bc

https://paper.tuisec.win/detail/cb5a91c63a97b8d