在http://www.justinshattuck.com/2007/01/18/mysql-injection-cheat-sheet/?akst_action=share-this上，有一節(jié)聲稱您可以使用某些亞洲字符編碼繞過mysql_real_escape_string用BIG5或GBK繞過mysql_real_escape_string（）“注入線”に關(guān)する追加情報(bào)：以上字符是中國Big5這是真的嗎？如果是的話，如果您無法訪問準(zhǔn)備好的陳述，那么如何保護(hù)您的網(wǎng)站呢？
3 回答
楊魅力
TA貢獻(xiàn)1811條經(jīng)驗(yàn) 獲得超6個(gè)贊
根據(jù)Stefan Esser的說法，“ mysql_real_escape_string()[ SET NAMES使用時(shí)不安全] ?！?/p>
來自他的博客的解釋：
SET NAMES通常用于將編碼從默認(rèn)設(shè)置切換到應(yīng)用程序需要的設(shè)置。這是mysql_real_escape_string不知道的方式完成的。這意味著，如果您切換到允許反斜杠作為2nd 3rd 4th…字節(jié)的多字節(jié)編碼，則會(huì)遇到麻煩，因?yàn)閙ysql_real_escape_string無法正確轉(zhuǎn)義。UTF-8是安全的…
更改編碼的安全方法是mysql_set_charset，但這僅在新的PHP版本中可用
他確實(shí)提到UTF-8是安全的。
慕標(biāo)琳琳
TA貢獻(xiàn)1830條經(jīng)驗(yàn) 獲得超9個(gè)贊
這是一個(gè)MySQL服務(wù)器錯(cuò)誤，據(jù)報(bào)道早在2006年5月就已修復(fù)。
看到：
MySQL錯(cuò)誤＃8303：具有包含\的多字節(jié)字符的字符串文字被錯(cuò)誤地詞匯化
MySQL Bug＃8317：查詢中的字符集介紹程序無法覆蓋連接字符集
MySQL錯(cuò)誤＃8378：字符串錯(cuò)誤地用客戶端字符集'gbk'逸出
MySQL的5.1.11 更新日志。
據(jù)報(bào)告該錯(cuò)誤已在MySQL 4.1.20、5.0.22、5.1.11中修復(fù)。
如果使用4.1.x，5.0.x或5.1.x，請確保至少已升級到次要修訂號。
解決方法是，您還可以啟用SQL模式NO_BACKSLASH_ESCAPES，該模式禁用反斜杠作為引號轉(zhuǎn)義字符。
青春有我
TA貢獻(xiàn)1784條經(jīng)驗(yàn) 獲得超8個(gè)贊
正如其他人所證明的，mysql_real_escape_string()在晦澀的邊緣情況下可以繞開。這是繞過轉(zhuǎn)義邏輯的一種已知策略，但是可能還有其他未知漏洞尚未發(fā)現(xiàn)。
防止PHP中的SQL注入的一種簡單有效的方法是在可能的地方使用準(zhǔn)備好的語句，在不能的地方使用非常嚴(yán)格的白名單。
經(jīng)證明的預(yù)處理語句在實(shí)際使用且不受PDO驅(qū)動(dòng)程序仿真時(shí)，被證明是安全的（至少在SQL注入方面），因?yàn)樗鼈兘鉀Q了應(yīng)用程序安全性的根本問題：它們將數(shù)據(jù)與對數(shù)據(jù)進(jìn)行操作的指令分開。它們以單獨(dú)的數(shù)據(jù)包發(fā)送；參數(shù)化的值永遠(yuǎn)不會(huì)有機(jī)會(huì)污染查詢字符串。
是2015年。不要逃脫和連接了。您仍然應(yīng)該根據(jù)應(yīng)用程序（和業(yè)務(wù)）邏輯來驗(yàn)證輸入，但是只使用準(zhǔn)備好的語句。
添加回答
舉報(bào)
0/150
提交
取消