SQL 注入防禦總結：預編譯綁定變量核心原理、框架配置、輸入驗證與編碼函數多層防護

SQL 注入是危害最高的 Web 漏洞之一，但防禦相對明確。本文從漏洞成因、核心防禦原理、框架層配置、輸入驗證、編碼函數兜底五個維度構建多層防護體系。

一、經典注入演示

-- 正常
SELECT id, no FROM user WHERE id = 2;

-- 注入：id = "2 OR 1=1"
SELECT id, no FROM user WHERE id = 2 OR 1=1;  -- 返回全表

-- 危險：id = "2; DROP TABLE sqlinject;"
-- 多語句執行導致表被刪

二、根因分析

本質：將用戶輸入的數據拼接為 SQL 命令執行，導致數據與代碼邊界模糊。

• 拼接字符串："SELECT * FROM t WHERE id=" + userInput
• 用戶輸入包含 SQL 關鍵字（OR、UNION、DROP）被解析為命令而非字面值。

三、核心防禦：預編譯 + 綁定變量（參數化查詢）

// JDBC 標準寫法
String sql = "SELECT id, no FROM user WHERE id = ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setInt(1, userId);  // 綁定變量
ResultSet rs = ps.executeQuery();

為什麼能防注入？

1. 語法分析前置：prepareStatement 階段完成 SQL 解析、語法樹構建、執行計劃生成，結構已固化。
2. 數據與代碼分離：後續 setXxx 傳入的參數只作為字面值參與執行，不再經過語法分析，其中的 SQL 關鍵字失去特殊含義。
3. 類型安全：setInt/setString 強制類型檢查，進一步收縮攻擊面。

四、主流框架配置檢查清單

五、無法預編譯場景的兜底防禦

1. 嚴格輸入驗證（白名單）

• 數字類型：正則 ^\d+$ 或 Integer.parseInt 異常捕獲。
• 枚舉值：IN ('A','B','C') 白名單校驗。
• 標識符（表名/列名）：映射表 Map 白名單轉換，絕不直接拼接。

2. 安全編碼函數（ESAPI / 驅動內建）

// ESAPI 範例
MySQLCodec codec = new MySQLCodec(Mode.STANDARD);
String safeName = ESAPI.encoder().encodeForSQL(codec, userName);
String sql = "SELECT * FROM user WHERE name = '" + safeName + "'";

• 編碼單引號、反斜線、控制字符等特殊字符，使其成為字面值一部分。
• 僅作為最後防線，優先級低於預編譯。

3. 最小權限資料庫賬號

• 應用賬號禁止 DROP/TRUNCATE/CREATE/FILE/SHUTDOWN 權限。
• 僅授予業務必需的 SELECT/INSERT/UPDATE/DELETE，且限定具體庫/表。

六、防禦深度檢查清單

1. 全代碼庫掃描：拼接 SQL 關鍵字（+/concat/||）+ 用戶輸入變量。
2. 框架配置審計：MyBatis ${}、Hibernate 拼接、JPA 原生 SQL。
3. 錯誤信息不回顯：生產環境關閉詳細 SQL 錯誤堆疊，返回通用錯誤碼。
4. WAF 部署：ModSecurity + OWASP CRS 規則集，攔截明顯注入特徵。
5. 日誌審計：記錄所有執行 SQL（含參數），定期異常模式分析。
6. 定期滲透測試：授權前提下進行自動化/手工注入掃描。