mysql_real_escape_string（）是否完全防止SQL注入？

Question

在http://www.justinshattuck.com/2007/01/18/mysql-injection-cheat-sheet/?akst_action=share-this上 ，有一節聲稱可以繞過某些亞洲字符編碼的mysql_real_escape_string

用BIG5或GBK繞過mysql_real_escape_string（）

“注射線”
に關する追加情報：

上面的字符是中文Big5

這是真的嗎？ 如果是這樣，如果您無法訪問預先准備好的聲明，您將如何保護您的網站不受此影響？

Answer 1

根據Stefan Esser的說法， “當使用SET NAMES時 ， mysql_real_escape_string()不安全。”

他的解釋來自他的博客 ：

SET NAMES通常用於將編碼從默認編碼切換到應用程序所需的編碼。 這是以mysql_real_escape_string不知道的方式完成的。 這意味着如果你切換到一些允許反斜杠作為第二個第3個第4個...字節的多字節編碼，你會遇到麻煩，因為mysql_real_escape_string沒有正確轉義。 UTF-8很安全......

更改編碼的安全方法是mysql_set_charset ，但這僅適用於新的PHP版本

但他確實提到UTF-8是安全的。

Answer 2

這是一個MySQL服務器錯誤，據報道已於2006年5月修復。

看到：

• MySQL bug＃8303 ：包含\\的多字節字符的字符串文字不正確
• MySQL Bug＃8317 ：查詢中的字符集介紹者無法覆蓋連接字符集
• MySQL Bug＃8378 ：使用客戶端字符集'gbk'錯誤地轉義字符串
• MySQL 5.1.11 changelog 。

在MySQL 4.1.20,5.0.22,5.1.11中修復了該錯誤。

如果使用4.1.x，5.0.x或5.1.x，請確保至少已升級到次要修訂號。

作為解決方法，您還可以啟用SQL模式NO_BACKSLASH_ESCAPES ，該模式禁用反斜杠作為引用轉義字符。

Answer 3

我很確定如果使用SQL來更改char編碼，它只會起作用。

Answer 4

正如其他人所證明的那樣， mysql_real_escape_string()可以在不起眼的邊緣情況下被繞過 。 這是繞過逃逸邏輯的一種已知策略，但可能還有其他尚未發現的未知漏洞。

在PHP中防止SQL注入的簡單而有效的方法是盡可能使用預准備語句 ，並且在不可能的情況下使用非常嚴格的白名單。

准備好的語句，當實際使用而不是由PDO驅動程序模擬時，可證明是安全的（至少在SQL注入方面），因為它們解決了應用程序安全性的基本問題：它們將數據與操作數據的指令分開。 它們是分開發送的; 參數化值永遠不會有污染查詢字符串的機會。

這是2015年。不要再逃避和連接了。 您仍應根據應用程序（和業務）邏輯驗證輸入，但只使用預准備語句。