前言：SQL 注入原理與危害

Web 應用未驗證/過濾使用者輸入，直接拼接 SQL 字串。攻擊者在 URL/表單注入惡意 SQL 片段，竊取/竄改/刪除資料，甚至提權至系統管理員（xp_cmdshell）、掛馬感染訪客。防禦必須多層次、纏深。

三步防禦策略

步驟 1：部署通用防注入程式碼（第一道防線）

在需防護頁面引入通用過濾庫（過濾單引號、註釋符、關鍵字等）。局限： 自動化注入分析工具 (SQLMap, Pangolin, Havij) 可繞過靜態規則，自動識別注入點並提取資料。

步驟 2：洞悉注入分析器邏輯，反制其弱點

實測發現：主流自動化工具不針對特定帳號名 (如 admin)，而是鎖定權限欄位（如 flag=1、is_admin=1、role=admin）。無論管理員帳號如何改名，只要權限標記存在，即會被鎖定。

步驟 3：佈設「蜜罐管理員」誘捕並拖垮分析器

1. 修改資料表結構： 管理員帳號欄位型別從 varchar(50) 改為 text / ntext / varchar(max)（支援超大長度）；密碼欄位同理。
2. 植入誘餌帳號 (ID=1)： 建立權限最高的假管理員帳號，密碼填入 超過 1000 個中文字元（或超長亂碼）。
3. 真實管理員藏匿： 真帳號置於 ID=549 或更大間隔，權限相同但密碼正常長度。
4. 前端登入頁加長度限制： <input maxlength="32"> 或後端驗證 len(pwd) <= 32。誘餌帳號密碼超長將被前端攔截，真帳號正常通過。

原理解析

• 自動化工具掃描到 ID=1 帳號權限最高 → 嘗試暴力/字典/彩虹表破解超長密碼 → 進入全負荷運算，甚至耗盡記憶體/CPU 導致工具當機/超時。
• 真管理員帳號隱藏於深處，工具通常僅掃描前 N 筆（預設 100~500），不易發現。
• 前端長度限制確保即使攻擊者獲得誘餌帳號密碼雜湊，也無法在登入介面輸入。

必要補充防禦（不可或缺）

• 參數化查詢 / 預編譯語句： 根治注入根本原因（PreparedStatement, sp_executesql, ORM 參數綁定）。
• 最小權限資料庫帳號： Web 應用連線帳號僅擁有必要 CRUD 權限，無 sysadmin、db_owner、xp_cmdshell。
• WAF (Web Application Firewall) 規則集： ModSecurity OWASP CRS、商用 WAF 虛擬補丁。
• 錯誤訊息不回顯： 關閉詳細錯誤頁面，避免洩露資料庫結構。
• 定期代碼審計與滲透測試： 靜態分析 (SAST) + 動態掃描 (DAST)。

結語：誘餌是戰術，參數化才是戰略

「誘餌帳號 + 巨型密碼 + 前端限制」是針對自動化掃描器的低成本戰術延遲手段，不能替代參數化查詢等根本修復。將兩者結合，並納入 SDLC 安全開發生命週期，才能真正封殺 SQL 注入威脅。