这个LINQ语句是否容易受到SQL注入攻击？

Question

这个LINQ语句是否容易受到SQL注入的攻击？

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

其中context是Entity，tests是一个表。 我正在尝试学习LINQ，我认为它的好处是它不容易受到sql注入，但我看到的一些东西却有不同的说法。我是否需要参数化这个LINQ语句以使其更安全？如果是这样，怎么样？

这也被认为是linq to sql或linq to entities？

Answer 1

简短回答：LINQ不容易受到SQL注入攻击。

答案很长：

LINQ与SQL不同。幕后有一个完整的库，它们从代码中的编译器生成的表达式树构建SQL，将结果映射到对象 - 当然，它会在路上安全地生成。

请参阅LINQ to SQL FAQ：

  

Q值。 LINQ to SQL如何受到保护   SQL注入攻击？

     

一个。 SQL注入一直是传统SQL的重大风险   通过连接用户形成的查询   输入。 LINQ to SQL避免了这种情况   使用SqlParameter进行注入   查询。用户输入变为   参数值。这种方法   防止恶意命令   用于客户输入。

在内部，这意味着当LINQ to 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。

Answer 2

没有。 LINQ to Entities和LINQ to SQL处理SQL查询的生成以避免SQL注入。如果您想要在使用各种输入运行此查询时看到生成的SQL语句，可以使用LINQPad。

它是LINQ to SQL还是LINQ to Entities取决于您的context对象是什么，并且无法从此代码段中确定。

在LINQ中唯一需要担心SQL注入的情况是，如果您使用ExecuteQuery方法来运行自定义SQL查询（see here）。但在那时，你已经离开了语言集成查询，回到了生成自己的字符串的世界。

Answer 3

LINQ使用参数化查询，因此它通常不易受SQL注入的影响。例如，您的示例不容易受到攻击。

Answer 4

LINQ to Entities提供程序使用参数化查询，对SQL注入完全安全。

Answer 5

LINQ To SQL生成参数化查询，以防止SQL注入攻击

Answer 6

Linq对所有查询进行了分类，因此不容易受到SQL注入攻击。但是，您仍应验证所有用户输入，否则您将面临跨站点脚本攻击。