本文實例講述了MySQL解決SQL注入的另類方法。分享給大家供大家參考，具體如下：

問題解讀

我覺得，這個問題每年帶來的成本可以高達數十億美元了。本文就來談談，假定我們有如下 SQL 模板語句：

select * from T where f1 = '{value1}' and f2 = {value2}

現在我們需要根據用戶輸入值填充該語句：

value1=hello
value2=5

我們得到了下面的 SQL 語句，我們再提交給數據庫：

select * from T where f1='hello' and f2=5

問題在于，攻擊者可以構造如下的用戶輸入值：

value1=anything' or 1=1 or f1='whatever
value2=5

拼接好的最終語句就變成了：

select * from T where f1='anything' or 1=1 or f1='whatever' and f2=5

攻擊者成功地改變了模板語句的語義。這種問題不單單發(fā)生在 SQL 上，還出現在通常使用模板的任何語言上，比如 HTML 和 shell 腳本。

常規(guī)解決方案的說明

SQL 是具備任意性和一致性的公理，token 和派生規(guī)則構成其公理化基礎。要注意的一個詞語是「任意性」。與 SQL 等價的公理化數不勝數。對于這種任意等價的表示，每一條合法的語句都能被準確地映射到 SQL 里的合法語句，其它語言亦然。在這種任意等價表示中，如果某語句是不合法的，那么它在 SQL 里也是不合法的。攻擊者不可能構造出可以滿足任何可能的、任意與 SQL 等價的規(guī)則。

策略1：根據不同的派生規(guī)則，用另一種語法擴展模板語句

例子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。重要的是它們在派生規(guī)則里的位置、而非它們的任意體現。你總是可以用其它 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，但是我們卻看到了攻擊者所引發(fā)的結果：

[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 語句本身的任意性，并要求所有現存不變量都符合任意的等價結構的規(guī)則。無需程序員的干預，就能自動完成。

攻擊者不得不符合一種未知的、任意的 brainfuck 語法的規(guī)則。想要符合一組未知的規(guī)則，將是難以解決的問題。因此，攻擊者通常無法得手。

更多關于MySQL相關內容感興趣的讀者可查看本站專題：《MySQL日志操作技巧大全》、《MySQL事務操作技巧匯總》、《MySQL存儲過程技巧大全》、《MySQL數據庫鎖相關技巧匯總》及《MySQL常用函數大匯總》

希望本文所述對大家MySQL數據庫計有所幫助。

最新評論