SQL Injection: MyBatis Mapper

透過不可信賴來源的輸入來建構的動態 SQL 陳述式可讓攻擊者修改陳述式的意義或是執行任意的 SQL 指令。

SQL Injection 錯誤會在以下情況中出現：

1.資料從一個不可信賴的來源進入程式。

2.資料用來動態建構 SQL 查詢。



MyBatis Mapper XML 檔案可讓您指定 SQL 陳述式中的動態參數，並使用 # 字元來進行典型定義，如下所示：

    <select id="getItems" parameterType="domain.company.MyParamClass" resultType="MyResultMap">
        SELECT *
        FROM items
        WHERE owner = #{userName}
    </select>

用括號括住變數名稱的 # 字元表示 MyBatis 將使用 userName 變數建立參數化查詢。不過，MyBatis 也可讓您使用 $ 字元，將變數直接串連至 SQL 陳述式，製造執行 SQL injection 的機會。

範例 1：以下程式碼動態地建構並執行了一個 SQL 查詢，該查詢可用來搜尋符合指定名字的項目。查詢僅會顯示項目所有者與目前已驗證使用者名稱相符的項目。

    <select id="getItems" parameterType="domain.company.MyParamClass" resultType="MyResultMap">
        SELECT *
        FROM items
        WHERE owner = #{userName}
        AND itemname = ${itemName}
    </select>

但是，由於這個查詢是連續固定基礎查詢字串和使用者輸入字串所動態建構而成的，所以只有在 itemName 沒有包含單引號字元的時候，查詢才會正確執行。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串 name' OR 'a'='a，那麼查詢將變成以下內容：

    SELECT * FROM items
    WHERE owner = 'wiley'
    AND itemname = 'name' OR 'a'='a';

加上 OR 'a'='a' 條件會使 WHERE 子句的評估永遠為 True，所以此查詢在邏輯上可等同於以下較簡化的查詢：

    SELECT * FROM items;

由於查詢理應只會傳回驗證使用者所擁有的項目，但簡化查詢會讓攻擊者不再受到此要求所限制；因此，查詢現在將會傳回所有儲存在 items 表中的項目，而不考慮指定的擁有者為何。

範例 2：此範例會檢查不同的惡意值傳送到建立的查詢以及在 Example 1 中執行的效果。如果使用者名稱為 wiley 的攻擊者在 itemName 中輸入字串「name'; DELETE FROM items; --」，那麼查詢將變成以下兩個查詢：

    SELECT * FROM items
    WHERE owner = 'wiley'
    AND itemname = 'name';

    DELETE FROM items;

    --'

許多的資料庫伺服器 (包括 Microsoft(R) SQL Server 2000)，允許一次執行多個由分號隔開的 SQL 陳述式。此攻擊字串會在 Oracle 和其他不允許整批執行由分號隔開陳述式的資料庫伺服器上造成錯誤，而在允許整批執行的資料庫上，此類的攻擊可讓攻擊者對資料庫執行任意的指令。

請注意這對連字符號 (--)，這在大部分的資料庫伺服器上都表示剩餘的陳述式，並視為註釋不予執行 [4]。在此案例中，註釋字元會從修改的查詢中將剩餘的一個單引號移除。在不允許以此方式使用註釋的資料庫中，一般攻擊者仍然可以使用類似 Example 1 中所示的訣竅進行攻擊。如果攻擊者輸入「name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a」字串，將會建立以下三個有效的陳述式：

    SELECT * FROM items
    WHERE owner = 'wiley'
    AND itemname = 'name';

    DELETE FROM items;

    SELECT * FROM items WHERE 'a'='a';

避免 SQL injection 攻擊的一個傳統方法為，將其視為輸入驗證的問題，只接受安全值允許清單中的字元，或是驗證並避免來自潛在惡意值的清單 (拒絕清單)。檢查允許清單是一種相當有效的方法，可強制執行嚴格的輸入驗證規則，而參數化 SQL 陳述式所需的維護較少，並且能提供更高的安全性保障。通常，對於實作拒絕清單方法，總是存在一些漏洞，所以無法有效避免 SQL injection 攻擊。例如，攻擊者可能：

- 將未列入黑名單的欄位當作目標
- 尋找方法以略過特定逸出中繼字元 (escape meta-character) 的需要
- 使用儲存的程序去隱藏插入的中繼字元

手動逸出在 SQL 查詢中字元的輸入有一定的幫助，但無法保證應用程式能免於 SQL injection 攻擊。

另外一個處理 SQL injection 攻擊的普遍建議方法為使用儲存的程序。雖然預存程序可防止某些類型的 SQL Injection 攻擊，但是對於大多數的攻擊還是無能為力。預存程序一般用來避免 SQL injection 攻擊的方式是，限制可以傳遞到參數的陳述式類型。但是，雖然有許多的限制方法，仍有許多危險的陳述式可以傳入儲存的程序中。所以再次強調，儲存的程序可以避免部分攻擊，但是並不能完全協助您的應用系統抵禦 SQL injection 的攻擊。