我在這里看到一些人指出，使用串聯(lián)查詢mysql_real_escape_string不會（完全）保護(hù)您免受SQL注入攻擊。但是，我還沒有看到一個輸入示例，該示例說明了mysql_real_escape_string無法保護(hù)您免受攻擊的攻擊。大多數(shù)示例都忘記了mysql_query僅限于一個查詢并且使用mysql_real_escape_string不正確。我能想到的唯一示例如下：mysql_query('DELETE FROM users WHERE user_id = '.mysql_real_escape_string($input));這不會保護(hù)您免受以下輸入的影響：5 OR 1=1我認(rèn)為這是不正確的用法，mysql_real_escape_string而不是缺點(diǎn)，它是為字符串而非數(shù)字值設(shè)計的。您應(yīng)該轉(zhuǎn)換為數(shù)字類型，或者如果要在消毒時將輸入視為字符串，則應(yīng)在查詢中執(zhí)行相同的操作，并在其周圍引起雙引號。誰能提供一個mysql_real_escape_string不依賴于數(shù)字值錯誤處理而又mysql_query可以僅執(zhí)行一個查詢的輸入示例嗎？編輯：我mysql_real_escape_string對替代品的局限性很感興趣，并且沒有將其與替代品進(jìn)行比較，我意識到新項目有更好的選擇，并且對此沒有爭議。
3 回答
臨摹微笑
TA貢獻(xiàn)1982條經(jīng)驗 獲得超2個贊
好的，除了mysql_*被棄用之外，我了解您想知道可能存在的任何可能的解決方法。也許這篇博客文章和幻燈片可能會揭示其中的一些內(nèi)容。
但是，正如這里的較早的問題所顯示的，強(qiáng)制轉(zhuǎn)換和引用并不能完全證明這一點(diǎn)。有太多事情可能出錯，而墨菲定律與那句永不止息的口號“永不信任網(wǎng)絡(luò)”纏繞在一起，將大錯特錯。
也許這篇文章，但最重要的是，該文章的后續(xù)內(nèi)容可以揭示更多的安全問題。老實(shí)說，我知道m(xù)ysql_real_escape_string即使與類型轉(zhuǎn)換和字符串格式結(jié)合使用也不是完全可靠的：
printf('WHERE id = \'%d\'',(int)mysql_real_escape_string($_REQUEST['id']));
無法涵蓋所有可能的攻擊。
我不是這方面的專家，但是我可以告訴您的是對每個輸入進(jìn)行消毒，如果有的話，將給您帶來虛假的安全感。大多數(shù)時候，您會（最初）知道如何以及為什么以及如何防御攻擊，但是您的同事卻可能不知道。他們可能會忘記某些事情，并且整個系統(tǒng)都將受到損害。
總結(jié)：是的，您也許能夠阻止任何形式的惡意輸入進(jìn)入您的數(shù)據(jù)庫，但是它需要執(zhí)行的每一項其他操作都會帶來額外的風(fēng)險。在那種情況下，最大的責(zé)任（一如既往）是周一早上沒有喝過第四杯咖啡的開發(fā)商。任何代碼，無論如何防御和深思熟慮，都無法保護(hù)自己免受怪物的侵害，因為怪物是脾氣暴躁，脾氣暴躁，對咖啡因和尼古丁無視的火雞。
千萬里不及你
TA貢獻(xiàn)1784條經(jīng)驗 獲得超9個贊
本身，我發(fā)布的代碼片段無法被AFAIK所利用，但會產(chǎn)生錯誤，并且在探測漏洞時會產(chǎn)生惡意，例如惡意調(diào)用ppl。您還很有可能在WHERE子句中使用1個以上的參數(shù)，每個參數(shù)都需要三個附加操作（字符串格式，類型強(qiáng)制轉(zhuǎn)換和轉(zhuǎn)義調(diào)用），因此此方法容易出錯（進(jìn)行強(qiáng)制轉(zhuǎn)換）或占位符錯誤，則不再安全）。在我也鏈接的問題中，排序規(guī)則的意義也提出了，我的摘錄根本沒有解決
添加回答
舉報
0/150
提交
取消