由於字元編碼問題，SQL 注入能否繞過「mysql_real_escape_string()」？

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

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

考慮以下PHP程式碼：

<code class="language-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'";</code>

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

攻擊方法：

攻擊依賴以下步驟：

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注入。

以上是由於字元編碼問題，SQL 注入能否繞過「mysql_real_escape_string()」？的詳細內容。更多資訊請關注PHP中文網其他相關文章！