Est-ce que ExecuteCommand de LINQ fournit une protection contre les attaques par injection SQL?

Question

J'ai une situation où j'ai besoin d'utiliser la méthode ExecuteCommand de LINQ pour exécuter une insertion.

Quelque chose comme (simplifié aux fins de cette question):

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

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

La question est de savoir si cela est une preuve d'injection SQL de la même manière des requêtes paramétrées sont?

Answer 1

fait quelques recherches, et je trouve ceci:

Dans mes tests simple, il ressemble à les paramètres passés dans les ExecuteQuery et ExecuteCommand méthodes sont automatiquement SQL codées en fonction de la valeur étant fournie . Donc si vous passez une chaîne avec un caractère ' , SQL l'échappera automatiquement à' '. Je crois qu'une politique similaire est utilisée pour d'autres types de données comme DateTimes, Décimales, etc.

http://weblogs.asp.net/scottgu/archive/2007/08/27/linq-to-sql-part-8-executing-custom-sql-expressions.aspx
(Vous avez défilement chemin vers le bas pour le trouver)

Cela me semble un peu étrange - la plupart des autres outils .Net savent mieux que "SQL escape" quoi que ce soit; ils utilisent des paramètres de requête réels à la place.

Answer 2

LINQ to SQL utilise exec_sql avec des paramètres, ce qui est beaucoup plus sûr que de concaténer dans la chaîne de requête ad-hoc. Il devrait être aussi sûr d'utiliser l'injection SQL que d'utiliser SqlCommand et sa collection Paramaters (en fait, c'est probablement ce que LINQ to SQL utilise en interne). Encore une fois, quel est le degré de sécurité que?