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