本文實例講述了MySQL解決SQL注入的另類方法。分享給大家供大家參考，具體如下：
問題解讀
我覺得，這個問題每年帶來的成本可以高達數十億美元了。本文就來談談，假定我們有如下 SQL 模板語句：
select * from T where f1 = '{value1}' and f2 = {value2} 現在我們需要根據用戶輸入值填充該語句：
value1=hellovalue2=5
我們得到了下面的 SQL 語句，我們再提交給數據庫：
select * from T where f1='hello' and f2=5
問題在于，攻擊者可以構造如下的用戶輸入值：
value1=anything' or 1=1 or f1='whatevervalue2=5
拼接好的最終語句就變成了：
select * from T where f1='anything' or 1=1 or f1='whatever' and f2=5
攻擊者成功地改變了模板語句的語義。這種問題不單單發生在 SQL 上，還出現在通常使用模板的任何語言上，比如 HTML 和 shell 腳本。
常規解決方案的說明
SQL 是具備任意性和一致性的公理，token 和派生規則構成其公理化基礎。要注意的一個詞語是「任意性」。與 SQL 等價的公理化數不勝數。對于這種任意等價的表示，每一條合法的語句都能被準確地映射到 SQL 里的合法語句，其它語言亦然。在這種任意等價表示中，如果某語句是不合法的，那么它在 SQL 里也是不合法的。攻擊者不可能構造出可以滿足任何可能的、任意與 SQL 等價的規則。
策略1：根據不同的派生規則，用另一種語法擴展模板語句
例子1：前綴語言
SQL 使用中綴表示法注1。中綴表示法等價于 lisp 風格的前綴表示法注2。中綴與前綴：
a OP1 b OP2 c <=> (OP1 a (OP2 b c))
a、b、c 是標識符或值，OP1、OP2 是操作符或功能。
前綴表示法的示例語句：
(select * T (and (= f1 '{value1}') (= f2 {value2}))) 該語句是等價的。它們在語義上屬于外延。自動把 SQL 的中綴表示法轉換成前綴表示法或其它表示法，都不算問題了。然而，攻擊者的注入在前綴語法方面就是不合法的：
語法錯誤。攻擊者想要的是：
這是不同的。攻擊者的注入不能輸出合法的前綴語言。
例子2：歐拉表示法
另一個替代方法將數得著歐拉表示法了。從中綴表示法到歐拉：
a OP1 b OP2 c <=> OP1(a,OP2(b,c))
例子中的語句：
select( *,T,and(=(f1,'{value1}'),=(f2,{value2}))) 而注入的語句將出現語法錯誤：
攻擊者本來是想寫成：
攻擊者正在做錯誤的事情。他的注入根本就沒有注意到所選的任意標記法。
例子3：對象標記法（object notation）
還有一種替代方法，對象標記法。從前綴表示法到對象：
a OP1 b OP2 c <=> a.OP1(b).OP2(c)
例子的代碼：
T.where(f1.=('{value1}').and(f2.=({value2})).select(*) 注入再一次折戟于語法：
T.where(f1.=('anything' or 1=1 or a='whatever').and(f2.=5)).select(*) 我不再提供正確答案了，讀者可以當做練習，看看攻擊者應該寫成什么樣子。
策略2：為 SQL 選擇其它任意 token
keyword 常常是一門語言里的任意 token。重要的是它們在派生規則里的位置、而非它們的任意體現。你總是可以用其它 keyword 替換現有 keyword，并且來回轉換。舉個例子，我們可以將下面 SQL 語句中的 keyword 轉換成我們姑且稱為「任意的 brainfuck」：
為了論證起見，我們將把操作數映射為 半任意的結構化序列：
T <=> @phai1Oa6@T@hello <=> @phai1Oa6@hello@
phai1Oa6 是任意選取的字符序列。對于當前情形，例子：
select * from T where f1 = '{value1}' and f2 = {value2} 變成了：
iph0ohKi ieZoh4xa aeZi5uja @phai1Oa6@T@ OoJ4aX4n @phai1Oa6@f1@ eeQu2Zad '{value1}' @phai1Oa6@and@ @phai1Oa6@f2@ eeQu2Zad {value2}
這是合法的、任意的 brainfuck 語言。經過注入之后，我們得到了：
iph0ohKi ieZoh4xa aeZi5uja @phai1Oa6@T@ OoJ4aX4n @phai1Oa6@f1@ eeQu2Zad 'anything' or 1=1 or a='whatever' @phai1Oa6@and@ @phai1Oa6@f2@ eeQu2Zad 5
你可以看到，它包含的 token 有 'or' 和 '='，它們在任意的 brainfuck 語言中是不合法的。我們的語法說，你必須這樣使用：
or <=> Ocaig5Es= <=> eeQu2Zad
這些 token 也不是操作數，因為它們將只能被視作：
or <=> @phai1Oa6@or@= <=> @phai1Oa6@=@
換句話說，注入之后的語句就變得不合法、也不可用了。
策略3：驗證不變量
你數數下面模板語句例子中的 token 有幾個？
[1] select [2] * [3] from [4] T [5] where [6] f1 [7] = [8] '{value1}' [9] and [10] f2 [11] = [12] {value2}
12 個。模板填充之后，總數必須仍然為 12，但是我們卻看到了攻擊者所引發的結果：
[1] select [2] * [3] from [4] T [5] where [6] f1 [7] = [8] 'anything' [9] or [10] 1 [11] = [12] 1 [13] or [14] a [15] = [16] 'whatever' [17] and [18] f2 [19] = [20] 5
現在有 20 個 token 。違反這種不變量，就暴露了有問題的地方。同樣適用于相同語句的表示，除了任意的、brainfuck 語言。模板的填充根本不可能導致 token 數量的變化。
事實上，你可以試著使用其它不變量，并在填充之后進行驗證。攻擊者必須和它們保持一致。
結論
有些人提倡，程序員在填充 SQL 模板時，應該更加小心。應對 SQL 注入問題，只是需要在編程方面多加小心。很明顯，這種方式算不上解決方案。人們仍然在校驗用戶輸入值方面出現錯誤，最終接受了帶有惡意的用戶輸入值。換句話說，單憑我們所有人更努力地工作，是無法根本解決這種問題的。
真正的解決方案在于，SQL 語句本身的任意性，并要求所有現存不變量都符合任意的等價結構的規則。無需程序員的干預，就能自動完成。
攻擊者不得不符合一種未知的、任意的 brainfuck 語法的規則。想要符合一組未知的規則，將是難以解決的問題。因此，攻擊者通常無法得手。
