NET中Entity Framework防范SQL注入的实用方法

在 EF Core SQL 注入防范中，有几个核心判断：EF Core 本身并不提供自动防注入机制，安全性完全取决于你选择哪条 API 以及如何传递参数。如果忽视这一点，那么FromSqlRaw 和 ExecuteSqlRaw 基本上等于裸奔——不手动进行参数化，就相当于把数据库的钥匙直接交给用户。

何时必须使用参数化？FromSqlRaw 和 ExecuteSqlRaw 的常见陷阱

这两个方法不会对字符串进行任何解析或转义处理，只是原封不动地将传入的字符串发送给数据库驱动。即使只拼接一个字段值，只要使用 + 或 $"" 插入用户输入，就会立即产生漏洞。

• FromSqlRaw($"SELECT * FROM Users WHERE Name = '{name}'") → 危险！C# 层已完成拼接，例如 'admin' OR 1=1 -- 可直接注入 SQL
• FromSqlRaw("SELECT * FROM Users WHERE Name = " + name) → 同样危险，字符串拼接发生在 EF 执行之前
• FromSqlRaw("WHERE Status = {0}", "Active") → 安全，EF 将 {0} 视为参数占位符，采用参数绑定机制
• FromSqlRaw("WHERE Name = @name", new SqlParameter("@name", name)) → 安全，显式构造参数对象，明确传递参数

FromSqlInterpolated 虽然便捷，但存在硬性限制

它能自动对插值变量进行参数化，但仅识别纯变量引用，不会处理表达式或拼接逻辑。

• ✅ context.Users.FromSqlInterpolated($"SELECT * FROM Users WHERE Name = {name}") → 安全，变量直接引用
• ✅ context.Users.FromSqlInterpolated($"SELECT * FROM Users WHERE CreatedAt > {DateTime.UtcNow.AddDays(-7)}") → 安全，表达式结果作为参数
• ❌ context.Users.FromSqlInterpolated($"SELECT * FROM Users WHERE Name LIKE {name + "%"}") → 危险！name + "%" 是 C# 表达式，其结果整体被当作参数，导致语义错误
• ❌ context.Users.FromSqlInterpolated($"SELECT * FROM Users WHERE {whereClause}") → 完全无效！whereClause 是字符串变量，会被整体当作参数值，导致 WHERE 条件失效

表名、列名、ORDER BY 等结构部分无法参数化

数据库引擎不支持对标识符（identifier）进行参数化，例如 FromSqlRaw("SELECT * FROM {0}", tableName) 在语法上本身就是非法的，EF 也不会帮助你校验或转义。

• 动态表名/列名必须采用白名单机制：例如仅允许 new[] { "Users", "Orders", "Products" } 中的值
• 排序字段和排序方向必须显式校验：例如 if (!new[] { "Name", "Email", "CreatedAt" }.Contains(sortField)) throw ...；if (sortDir != "ASC" && sortDir != "DESC") throw ...
• 禁止使用 string.Concat、StringBuilder 或 Replace 进行所谓的“关键词过滤”来糊弄——例如删除了 "or"，但 "oR" 或换行符仍然可以绕过防护

真正棘手的并非写对那几行参数化代码，而是需要时刻分清“数据”与“结构”：值可以参数化，但 SQL 骨架必须依赖白名单来兜底。只要漏掉任何一个动态拼接点，整条防护链就会失效。