2008-10-01 12 views
15

Mam sytuację, w której muszę użyć metody ExecuteCommand LINQ do uruchomienia insert.Czy funkcja ExecuteCommand LINQ zapewnia ochronę przed atakami typu SQL injection?

Coś (uproszczone dla celów tego pytania):

object[] oParams = { Guid.NewGuid(), rec.WebMethodID }; 

TransLogDataContext.ExecuteCommand (
"INSERT INTO dbo.Transaction_Log (ID, WebMethodID) VALUES ({0}, {1})", 
oParams); 

Pytanie brzmi, czy to jest SQL injection dowód w taki sam sposób sparametryzowane zapytania są?

Odpowiedz

14

Czy jakieś badania i znalazłem to:

W moim prostych testów, wygląda parametry przekazywane w executeQuery i ExecuteCommand metod są automatycznie SQL zakodowane na podstawie wartości dostarczane . Więc jeśli przejdą na sznurku z ' charakteru, zostanie ona automatycznie SQL uciec do «». Wierzę podobny polityka jest używany do innych typów danych jak DateTimes, dziesiętne, itd

http://weblogs.asp.net/scottgu/archive/2007/08/27/linq-to-sql-part-8-executing-custom-sql-expressions.aspx
(trzeba przewijać w dół, aby go znaleźć)

To wydaje się trochę dziwne dla mnie - większość innych narzędzi .Net wie lepiej niż "ucieczka SQL"; zamiast tego używają prawdziwych parametrów zapytania.

+8

jego autora, ScottGu \ jest czymś więcej niż tylko losowe faceta w sieci! http://en.wikipedia.org/wiki/Scott_Guthrie – nathaniel

0

LINQ do SQL używa exec_sql z parametrami, co jest znacznie bezpieczniejsze niż konkatenacja w łańcuchu zapytań ad-hoc. To powinno być tak samo bezpieczne againt SQL injection, jak przy użyciu SqlCommand i jej kolekcja paramaters (w rzeczywistości jest to prawdopodobnie co LINQ to SQL używa wewnętrznie). Potem znowu, jak bezpieczny jest że?

+0

SqlCommand i parametry są bezpieczne, chyba że procedura przechowywana jest nazywany manipuluje struny do procesu o sp_exec. – DamienG

Powiązane problemy