三步徹底防範 SQL 注入：從原理到實戰防禦

SQL 注入是 Web 應用程式最常見也最危險的安全漏洞之一。攻擊者透過未經過濾的輸入欄位注入惡意 SQL 代碼，竊取、竄改甚至刪除資料庫資料，嚴重時可取得系統管理員權限。本文從攻擊原理出發，提出三階段防禦策略，幫助開發人員建立多層次防護體系。

什麼是 SQL 注入？

當應用程式直接將使用者輸入拼接進 SQL 陳述式，且未進行參數化或過濾，攻擊者即可輸入如 ' OR '1'='1 等惡意字串，改變查詢邏輯，繞過驗證或執行任意指令。常見攻擊向量包括網址列參數、表單欄位、Cookie、HTTP Header 等。

第一階段：基礎防注入模組（攔截手動測試）

在頁面載入初期引入通用防注入程式碼，過濾常見關鍵字（SELECT、UNION、-- 等），可阻擋大部分手動測試。但自動化注入分析工具（如 SQLMap）能輕易繞過關鍵字過濾，需進階防禦。

第二階段：識別與對抗注入分析器

實驗發現，自動化工具並非鎖定特定帳號（如 admin），而是針對「權限欄位」（如 flag=1）進行暴力嘗試。因此，單純修改管理員帳號名稱無效，必須從權限模型著手防禦。

第三階段：蜜罐帳號與輸入長度限制（核心殺招）

1. 修改資料表結構： 將帳號、密碼欄位型別改為大型文字型別（如 VARCHAR(MAX) 或 NVARCHAR(MAX)），支援超長字串。
2. 建立誘餌帳號（ID=1）： 設置擁有最高權限的假管理員帳號，密碼填入超過 1000 字的中文字串。當注入工具嘗試破解此帳號時，龐大的字串組合會導致分析器進入全負荷運算，甚至資源耗盡當機。
3. 真實管理員帳號隱藏（ID>1）： 將真實管理員帳號置於較大 ID（如 549），並確保登入頁面對帳號、密碼長度進行嚴格限制（如不超過 20 字元），誘餌帳號因超長而被前端攔截，真實帳號正常通過。

總結：參數化查詢（Prepared Statement）才是根本解決之道。上述三階段策略可作為緩解措施或深度防禦的一環，但不應取代安全編碼規範。