利用字符編碼問題繞過mysql_real_escape_string()的SQL注入

儘管mysql_real_escape_string()函數可以防止SQL注入，但在某些特定情況下，它可能會被繞過。

考慮以下PHP代碼：

$login = mysql_real_escape_string(GetFromPost('login'));
$password = mysql_real_escape_string(GetFromPost('password'));

$sql = "SELECT * FROM table WHERE login='$login' AND password='$password'";

這段代碼看似安全，但由於字符集編碼的邊緣情況，它可能被利用。

攻擊方法：

攻擊依賴於以下步驟：

1. 設置字符集： 選擇一種編碼（例如，gbk），其中相同的字節序列既表示非ASCII字符，也表示ASCII反斜杠（'\'）。
2. 構造有效載荷： 使用精心構造的有效載荷，其中包含無效的多字節字符，確保其最後一個字節表示ASCII反斜杠。
3. 調用mysql_real_escape_string()： 客戶端認為連接使用的是不同的字符集（例如，latin1），因此mysql_real_escape_string()會在單引號前插入反斜杠，從而產生語法上有效的字符串。
4. 提交查詢： 轉義後的有效載荷成為SQL語句的一部分，允許攻擊者繞過預期的保護。

工作原理：

關鍵問題在於服務器期望的字符集與客戶端認為的字符集不匹配。雖然mysql_real_escape_string()根據客戶端設置的連接編碼進行轉義，但在某些情況下，它會將無效的多字節字符視為單個字節，包括使用SET NAMES 而不是mysql_set_charset()的情況。

後果：

即使禁用了模擬預處理語句，此攻擊也可以繞過PDO的模擬預處理語句。

補救措施：

使用非易受攻擊的字符集，如utf8mb4或utf8，可以減輕此問題。啟用NO_BACKSLASH_ESCAPES SQL模式也可以提供保護。

安全的示例：

始終使用mysql_set_charset()或PDO的DSN字符集參數正確設置字符集。 MySQLi中的真實預處理語句也對這種攻擊免疫。

結論：

雖然mysql_real_escape_string()通常提供強大的保護，但務必注意此類潛在的邊緣情況，以確保全面防禦SQL注入。