mysql_real_escape_string() 足以預防 SQL 注入嗎?
雖然許多人認為使用 mysql_real_escape_string() 可以防止 SQL注入,但確實存在旁路
缺陷
在特定情況下,例如:
mysql_query('SET NAMES gbk'); $var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*"); mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");
由於伺服器預期字元不匹配而出現問題設定和客戶的看法。透過使用 'SET NAMES' 修改伺服器上的字元集,mysql_real_escape_string() 可能會轉義 ' 為 ASCII,而伺服器期望它為純文字。這會產生差異,允許自由懸掛 ' 和注入。
壞處
PDO 對準備好的語句的預設模擬也可能導致此漏洞。建議停用模擬,但對不支援的查詢回退到模擬可能會阻止完全保護。
醜
在 MySQL 4.1.20之前,存在允許無效多位元組字元的錯誤就像在有效負載中看到的那樣,即使使用正確的客戶端字元集,也會將其轉義為單一位元組
可取之處
使用不可滲透的字元集(如utf8mb4 或utf8),或啟用NO_BACKSLASH_ESCAPES SQL模式,可以防止這種情況
結論
使用 mysql_real_escape_string() 在許多情況下仍然有效,但了解潛在的邊緣情況至關重要。使用枚舉欄位和預先準備語句等安全性技術以及正確的字元集和模式配置對於全面的 SQL 注入防護至關重要。
以上是`mysql_real_escape_string()` 真的能防止 SQL 注入嗎?的詳細內容。更多資訊請關注PHP中文網其他相關文章!