MySQL 防 SQL 注入另類思路：隨機化語法模板與不變量驗證

SQL 注入防禦新視角：語法隨機化與不變量驗證

傳統參數化查詢雖有效但依賴開發者自覺。本文探討三種「另類」防禦策略：語法替換、Token 隨機化、不變量驗證，從語言本質層面切斷注入路徑。

一、問題本質回顧

模板：SELECT * FROM T WHERE f1 = '{value1}' AND f2 = {value2}

攻擊輸入：value1=anything' OR 1=1 OR f1='whatever

結果：SELECT * FROM T WHERE f1='anything' OR 1=1 OR f1='whatever' AND f2=5

攻擊者成功改變語義，繞過原本邏輯。

二、策略一：換語法表示法（保持語義等價）

SQL 具有任意性，同一語義可用不同語法表達。攻擊者注入的是標準 SQL 語法，若我們內部使用非標準語法，注入即失效。

1. 前綴表示法（Lisp 風格）

標準：a OP1 b OP2 c
前綴：(OP1 a (OP2 b c))

模板：(SELECT * T (AND (= f1 '{value1}') (= f2 {value2})))
注入後：(SELECT * T (AND (= f1 'anything' OR 1=1 OR a='whatever') (= f2 5)))  -- 語法錯誤
攻擊者真意：(SELECT * T (OR (= f1 'anything') (OR (= 1 1) (AND (= a 'whatever') (= f2 5)))))

2. 歐拉表示法（函數式）

標準：a OP1 b OP2 c
歐拉：OP1(a, OP2(b, c))

模板：SELECT(*, T, AND(=(f1, '{value1}'), =(f2, {value2})))
注入同樣導致語法錯誤

3. 物件標記法

標準：a OP1 b OP2 c
物件：a.OP1(b).OP2(c)

模板：T.WHERE(f1.='{value1}').AND(f2.={value2}).SELECT(*)
注入同樣失效

三、策略二：隨機化關鍵字 Token

將 SQL 關鍵字映射為隨機生成的 Token，每次部署/啟動重新生成：

映射表：
SELECT → iph0ohKi
*      → ieZoh4xa
FROM   → aeZi5uja
WHERE  → OoJ4aX4n
=      → eeQu2Zad
...    

操作數包裝：T → @phai1Oa6@T@

最終語句：
iph0ohKi ieZoh4xa aeZi5uja @phai1Oa6@T@ OoJ4aX4n @phai1Oa6@f1@ eeQu2Zad '{value1}' @phai1Oa6@and@ @phai1Oa6@f2@ eeQu2Zad {value2}

攻擊者注入的 OR、= 在隨機語法中均為非法 Token，無法構造有效語句。

四、策略三：驗證模板不變量

模板 Token 總數固定（例：12 個）。填充後若 Token 數變化（如變 20 個），即判定被注入。

原模板：[SELECT][*][FROM][T][WHERE][f1][=][{value1}][AND][f2][=][{value2}] = 12 tokens
注入後：[SELECT][*][FROM][T][WHERE][f1][=][anything][OR][1][=][1][OR][a][=][whatever][AND][f2][=][5] = 20 tokens
→ 違反不變量，拒絕執行

其他可驗證不變量：AST 節點數、語法樹深度、關鍵字出現次數等。

五、結論與落地建議

• 上述策略核心：將「信任開發者小心」轉為「系統自動保證」
• 工程落地可構建 SQL 編譯器中介層：開發寫標準 SQL → 編譯器隨機化 Token / 轉換語法 / 驗證不變量 → 執行引擎解碼執行
• 攻擊者面對未知隨機語法/Token，構造有效注入極難（等價於破解單次一密系統）
• 現有成熟方案：參數化查詢（Prepared Statement） 已在協議層解決語義混淆，仍是首選；上述思路可作為深度防禦第二層或存量系統無法改造時的緩解方案

安全本質是提高攻擊成本，語法隨機化與不變量驗證從根本上改變了攻擊者的成本結構。