3 回答

TA貢獻1811條經驗 獲得超6個贊
根據Stefan Esser的說法,“ mysql_real_escape_string()[ SET NAMES使用時不安全] 。”
來自他的博客的解釋:
SET NAMES通常用于將編碼從默認設置切換到應用程序需要的設置。這是mysql_real_escape_string不知道的方式完成的。這意味著,如果您切換到允許反斜杠作為2nd 3rd 4th…字節的多字節編碼,則會遇到麻煩,因為mysql_real_escape_string無法正確轉義。UTF-8是安全的…
更改編碼的安全方法是mysql_set_charset,但這僅在新的PHP版本中可用
他確實提到UTF-8是安全的。

TA貢獻1830條經驗 獲得超9個贊
這是一個MySQL服務器錯誤,據報道早在2006年5月就已修復。
看到:
MySQL錯誤#8303:具有包含\的多字節字符的字符串文字被錯誤地詞匯化
MySQL Bug#8317:查詢中的字符集介紹程序無法覆蓋連接字符集
MySQL錯誤#8378:字符串錯誤地用客戶端字符集'gbk'逸出
MySQL的5.1.11 更新日志。
據報告該錯誤已在MySQL 4.1.20、5.0.22、5.1.11中修復。
如果使用4.1.x,5.0.x或5.1.x,請確保至少已升級到次要修訂號。
解決方法是,您還可以啟用SQL模式NO_BACKSLASH_ESCAPES
,該模式禁用反斜杠作為引號轉義字符。

TA貢獻1784條經驗 獲得超8個贊
正如其他人所證明的,mysql_real_escape_string()
在晦澀的邊緣情況下可以繞開。這是繞過轉義邏輯的一種已知策略,但是可能還有其他未知漏洞尚未發現。
防止PHP中的SQL注入的一種簡單有效的方法是在可能的地方使用準備好的語句,在不能的地方使用非常嚴格的白名單。
經證明的預處理語句在實際使用且不受PDO驅動程序仿真時,被證明是安全的(至少在SQL注入方面),因為它們解決了應用程序安全性的根本問題:它們將數據與對數據進行操作的指令分開。它們以單獨的數據包發送;參數化的值永遠不會有機會污染查詢字符串。
是2015年。不要逃脫和連接了。您仍然應該根據應用程序(和業務)邏輯來驗證輸入,但是只使用準備好的語句。
添加回答
舉報