dynamicLINQ可以注入吗？

使用dynamicLINQ库（链接），是否容易注入？（如果是的话）如何防范呢？

安全考虑（entity framework）的一些背景：

LINQ to Entities注入攻击：

尽pipe查询组合在LINQ to Entities中是可能的，但它是通过对象模型API执行的。与实体SQL查询不同，LINQ to Entities查询不是使用string操作或串联组成的，而且它们不易受传统SQL注入攻击的影响。

由于dynamicSQL是使用string组成的，这是否意味着它可能容易受到注入向量？或者，LINQ to SQL会根据Dynamic LINQ库中的基础数据types自动处理参数化值？

或者它是完全安全的，因为dynamic查询将在内存中执行，而不是针对SQL（从而否定SQL索引的好处）？

我一直在通过理解DynamicLibrary.cs代码，但我相信我可以轻松地忽略一些东西。

由于这个问题是关于dynamicLINQ库本身，这个问题可以被认为适用于linq-to-sql和linq-to-entities （尽pipe上面引用了entity framework）。

那么，我不同意在Dynamic Linq中注入是不可能的。

在“ 回答 ”中描述的内容是正确的，但是符合在给定语言中构build的标准Linq（C＃或VB.Net），或者通过调用类似lambda函数的扩展方法。

那么，真的，不可能注入任何东西，因为.NET Linq to Sql翻译器当然是写得很好的。因此，“SQL注入”是不可能的，这是真的。

然而，dynamicLinq有可能是“Linq注入”攻击。在对OP引用的linq安全性的解释中，指出：

LINQ to Entities查询不是通过使用string操作或串联组成的，它们不易受传统SQL注入攻击的影响。

基本上这是一个要点。如果查询是由string操作组成，那么它很容易发生注入攻击。而dynamicLinq实际上是由string组成的，因此它可能容易受到注入的攻击。

很明显，攻击者必须意识到使用DynamicLinq的事实，并且只能攻击准备好的数据，以便导致有效的恶意Dynamic Linq查询。

我想强调这个事实 – 最终的SQL是安全的 ，但是原始的dynamicLinq是否安全取决于你 。

必须使您的dynamiclinq查询安全的是为所有用户input使用占位符 。永远不要连接你的string！

想象下面的查询：

 dataset.Where("allowed == 1 and code == \"" + user_entered_data + "\"");

如果input没有被消毒并且没有被转义，攻击者可能会input：

 200" or allowed == 0 and code == "200

这将导致：

 allowed == 1 and code == "200" or allowed == 0 and code == "200"

为了避免这种情况，你应该使用占位符：

 dataset.Where("allowed == 1 and code == @0", user_entered_data);

DynamicLinq将使占位符（在这种情况下：用户input的数据）一个lambda参数（而不是连接到查询），并依赖Linq-To-Entities（或任何后端）安全地转换为SQL。

从我从检查System.Data.Linq命名空间知道的是，从LINQ查询构buildSQL对象树，并且作为此过程的一部分，将调用SqlParameterizer类以将所有内联值replace为参数。然后将这些值分配给参数。所以SQL注入攻击应该是不可能的。