Entity Framework Core：表达式构造防SQL注入的安全性与应用疑问

核心结论 #

用表达式树构造动态查询完全可以防范SQL注入，EF Core会将表达式树解析为参数化SQL，和手写常规Linq查询的安全级别一致。

为什么这种方法没被广泛推荐作为防注入方案？ #

• 复杂度较高：手动编写表达式树的代码量远多于使用参数化FromSqlInterpolated、Linq.Dynamic.Core等工具，维护成本高，对普通开发者门槛也更高。
• 已有更易用的替代方案：大部分动态查询场景，用EF Core内置的参数化SQL方法、第三方动态Linq库就能满足需求，没必要手动拼接表达式树。
• 文档侧重易用性：微软官方文档优先推荐对开发者更友好的方案，手动表达式树属于进阶技巧，受众范围窄，因此不会作为防注入的主流方案重点提及。

两种示例的安全性对比 #

不安全的FromSqlRaw写法

public List<Blogs> GetFilteredBlogs(string filterField, string filterValue) 
{
    List<Blogs> blogs = context.Blogs
                               .FromSqlRaw($"select * from Blogs where {filterField} = {filterValue}");
    return blogs;
}

这种写法直接将用户输入的filterField和filterValue拼接进SQL字符串，无论是字段名还是值都存在注入风险。比如filterField传入1=1--，最终SQL会变成select * from Blogs where 1=1-- = ...，直接绕过过滤逻辑。

安全的表达式树写法

public List<Blogs> GetFilteredBlogs(string filterField, string filterValue) 
{
    ParameterExpression entity = Expression.Parameter(typeof(Blog));
    MemberExpression entityProperty = Expression.Property(entity, filterField);
    ConstantExpression valueConstant = Expression.Constant(filterValue);
    BinaryExpression equal = Expression.Equal(entityProperty, valueConstant);
    LambdaExpression filter = Expression.Lambda<Func<Blog, bool>>(equal, entity);
    
    List<Blogs> blogs = context.Blogs.Where(filter).ToList();

    return blogs;
}

EF Core处理这个表达式树时，会：

1. 验证filterField对应的实体属性是否存在（不存在则抛出异常）；
2. 将filterValue作为参数传入SQL，生成类似WHERE [Blog].[AllowedField] = @p0的参数化语句，彻底避免值注入；
3. 生成的字段名是EF Core根据实体映射规则生成的安全标识符，不存在字段名注入的风险。

额外注意点 #

你提到的「已针对可访问列设置防护措施」非常关键：必须先校验filterField是否在允许的列列表中，否则用户可能通过传入不存在的字段名触发异常，或访问敏感列导致数据泄露——但这属于权限控制问题，并非SQL注入风险。

内容的提问来源于stack exchange，提问作者Myliak