这个 LINQ 语句是否容易受到 SQL 注入的影响？
var result = from b in context.tests
where b.id == inputTextBox.Text
select b;
其中 context 是一个实体，而 tests 是一个表。 我正在尝试学习 LINQ，我认为它的好处是它不容易受到 sql 注入的影响，但是我看到的一些东西有不同的说法。我需要对这个 LINQ 语句进行参数化以使其更安全吗？如果有，怎么做？
这也将被视为 linq to sql 或 linq to entity？
【问题讨论】：
标签： asp.net linq-to-sql linq-to-entities
简答：LINQ 不易受到 SQL 注入的攻击。
长答案：
LINQ 不像 SQL。幕后有一个完整的库，可以从编译器从代码中生成的表达式树构建 SQL，将结果映射到对象——当然，它还负责确保过程中的安全。
问。如何保护 LINQ to SQL SQL 注入攻击？
A. 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，就像任何抽象技术一样，了解幕后发生的事情既令人着迷又非常有用。
附：每次看到关于 SQL 注入的问题都会忍不住想起这个网络漫画。
【讨论】：
LINQ 使用参数化查询，因此它通常不易受到 SQL 注入的影响。例如，您的示例并不容易受到攻击。
【讨论】：
LINQ to Entities 提供程序使用参数化查询，并且对 SQL 注入完全安全。
【讨论】：
没有。 LINQ to Entities 和 LINQ to SQL 处理 SQL 查询的生成以避免 SQL 注入。如果您想知道在使用各种输入运行此查询时会生成什么 SQL 语句，您可以使用 LINQPad。
是 LINQ to SQL 还是 LINQ to Entities 取决于你的 context 对象是什么，无法从这段代码 sn-p 中确定。
您需要担心 LINQ 中的 SQL 注入的唯一情况是您使用 ExecuteQuery 方法运行自定义 SQL 查询 (see here)。但此时，您已经离开了 Language-INtegrated Query，回到了生成自己的字符串的世界。
【讨论】：
LINQ To SQL 生成参数化查询，以防止 SQL 注入攻击
【讨论】：
Linq 将所有查询参数化，因此不易受到 SQL 注入攻击。但是，您仍应验证所有用户输入，否则您将面临跨站点脚本攻击。
【讨论】：