此LINQ語句是否容易受到SQL注入的影響？

這是LINQ統計容易受SQL注入？此LINQ語句是否容易受到SQL注入的影響？

var result = from b in context.tests 
    where b.id == inputTextBox.Text 
    select b;

其中上下文是一個實體和測試是一個表。我試圖學習LINQ，我認爲它的好處是它不容易被sql注入，但是我看到的一些東西有不同的說法。我需要參數化這個LINQ語句以使它更安全嗎？如果是這樣，怎麼樣？

也將這被認爲是LINQ到SQL或LINQ實體？

來源

2010-09-29 Peter

簡短的回答：LINQ是不容易受到SQL注入。

龍答：

LINQ是不是像SQL。在後臺有一個完整的庫，它可以從代碼中編譯器生成的表達式樹構建SQL，將結果映射到對象 - 當然，這樣做會使得事情變得安全。

見LINQ to SQL FAQ：

問：如何是LINQ to SQL的保護 SQL注入攻擊？

答：SQL注入對於通過連接用戶輸入形成的傳統SQL 存在重大風險。 LINQ to SQL通過在查詢中使用SqlParameter避免了這樣的注入。用戶輸入變爲參數值。這種方法可防止從客戶輸入中使用惡意命令。

在內部，它意味着當LINQ到SQL查詢數據庫，而不是使用簡單的值，它通過它們作爲SQL參數，這意味着它們可以從未被作爲由數據庫的可執行代碼進行處理。大多數（如果不是全部的話）ORM映射器也是如此。

比較這兩種方法（完全僞代碼）：

string name = "' ; DROP DATABASE master --" 
run ("SELECT * FROM Authors WHERE Name = '" + name + "'") // oops! 

// now we'd better use parameters 
SqlParameter name = new SqlParameter ("@name", "' ; DROP DATABASE master --") 
run ("SELECT * FROM Authors WHERE Name = @name", name) // this is pretty safe

我建議你更深入地研究什麼LINQ語句的實際含義和何時以及如何得到它們轉換爲真正的SQL。您可能想了解LINQ standard query operator translation，deferred execution，different LINQ providers等等。在LINQ的情況下，就像任何抽象技術一樣，這對於瞭解幕後發生的事情來說既迷人又非常有用。

P.S.每當我看到一個關於SQL注入的問題時，我都忍不住想起這個webcomic。

sql injection