【问题标题】：Entity Framework + sql injection实体框架+sql注入
【发布时间】：2017-01-14 12:41:09
【问题描述】：

我正在建立一个IQueryable，我在其中应用相关过滤器，我在这里遇到了这行代码。

items = items.OrderBy(string.Format("{0} {1}", sortBy, sortDirection));

这个 sn-p 是否容易受到 SQL 注入的攻击？或者这些（字符串）参数是否在幕后参数化？我以为所有 Linq 查询都为我转义和参数化了，但我能够像这样直接传递一个字符串这一事实让我失望。

【问题讨论】：

这种说法对你有用吗？你有实现它的静态扩展方法吗？我不熟悉OrderBy不带lamba表情。
此扩展位于 System.Linq.Dynamic 命名空间中。带有方法签名static IQueryable<T> OrderBy<T>(this IQueryable<T> source, string ordering, params object[] values)。
看起来 System.Linq.Dynamic 是托管在 CodePlex 上的开源项目。源代码位于dynamiclinq.codeplex.com/SourceControl/latest#DynamicLinq/…。据我所知，他们正在获取字符串数据并使用它来修改表达式树，所以，不，它不容易受到 SQL 注入的攻击。

【解决方案1】：

第一点：

由于以下原因，您必须避免从暴露给潜在不受信任的调用者的方法中返回 IQueryable<T> 类型：

公开IQueryable<T> 类型的查询的使用者可以调用暴露安全数据或增加结果大小的方法结果集。 例如，考虑以下方法签名：

public IQueryable<Customer> GetCustomer(int customerId)

此查询的使用者可以在返回的 IQueryable<Customer> 上调用 .Include("Orders") 以检索查询不打算公开的数据。这可以通过将方法的返回类型更改为IEnumerable<T> 并调用具体化结果的方法（例如.ToList()）来避免。

因为IQueryable<T>查询是在结果为迭代，一个查询的消费者，暴露了一个IQueryable<T> type 可以捕获抛出的异常。 Exceptions 可能包含并非面向消费者的信息。

第二点：

如何防范 SQL 注入攻击？

通过将malicious input 提供给query predicate 和parameter names 中使用的值，可以在实体SQL 中执行SQL 注入攻击。

为了避免 SQL 注入的风险

您不应该将用户输入与 Entity SQL 命令文本结合起来

Entity SQL 查询accept parameters 接受文字的任何地方。 您应该使用参数化查询，而不是将来自外部代理的文字直接注入到查询中。您还应该考虑使用查询构建器方法来安全地构造 Entity SQL。

虽然查询组合在 LINQ to Entities 中是可能的，但它是通过对象模型 API 执行的。与 Entity SQL 查询不同，LINQ to Entities 查询不是通过使用字符串操作或串联组成的，它们不易受到传统 SQL 注入攻击。

【讨论】：