SQL Injection: LINQ

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

下列情況下會發生與 LINQ 有關的注入錯誤：

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

2. 此資料將用來動態建構查詢。
範例 1：以下程式碼動態地建構並執行 LINQ 查詢，以搜尋符合指定名稱的項目。查詢僅會顯示 owner 與目前已驗證使用者名稱相符的項目。

...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";

var items = dataContext.ExecuteCommand<Item>(query);
...

此查詢欲執行以下程式碼：

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

但是，由於這個查詢是連續固定基礎查詢字串和使用者輸入字串所動態建構而成的，所以只有在 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';

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

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

手動去除在 LINQ 查詢中特殊字元的輸入有一定的幫助，但無法完全保護您的應用程式免於 LINQ Injection 攻擊。

另外一個處理 LINQ Injection 攻擊的普遍建議方法為使用儲存的程序。雖然儲存的程序可避免某些類型的 LINQ Injection 攻擊，但是對於大多數的攻擊還是無能為力。儲存的程序一般用來避免 LINQ Injection 攻擊的方式是，限制可以傳送到參數的指令類型。但是，雖然有許多的限制方法，仍有許多危險的指令可以傳入儲存的程序中。所以再次強調，儲存的程序可以避免部分攻擊情況，但無法保護您的應用程式免於 LINQ Injection 攻擊。