linq to sql 本身不产生 sql 注入漏洞，因其默认使用参数化查询；但 fromsqlraw、executequery 等手动拼接字符串的操作会绕过防护导致注入风险。
LINQ to SQL 本身不会产生 SQL 注入漏洞，只要你不用 ExecuteQuery、ExecuteCommand 或拼接字符串构造查询 —— 但很多人误以为“用了 LINQ 就绝对安全”，结果在边界场景翻车。
为什么 LINQ 查询通常免疫 SQL 注入
LINQ to SQL（以及 EF Core 的大部分 LINQ 查询）底层使用表达式树编译为参数化 SQL，所有用户输入都作为独立参数传入，数据库驱动自动处理转义。比如：
var users = context.Users.Where(u => u.Name == userName).ToList();
生成的 SQL 类似 SELECT * FROM Users WHERE Name = @p0，userName 值不会进入 SQL 文本，只作为参数绑定。
这意味着：只要不主动跳出 LINQ 安全区，就不存在注入路径。
哪些 LINQ 场景会实际触发 SQL 注入风险
真正危险的不是 Where 或 OrderBy，而是你手动“破防”的几个操作：
- 用
context.Users.FromSqlRaw("SELECT * FROM Users WHERE Name = '" + name + "'")—— 字符串拼接直接绕过所有防护 - 调用
DataContext.ExecuteQuery<t>("SELECT * FROM " + tableName)</t>—— 表名/列名无法参数化，拼接即高危 - 在
DataContext.ExecuteCommand中拼接条件，如.ExecuteCommand("UPDATE Users SET Status = '" + status + "' WHERE Id = " + id) - 把用户输入塞进
Expression.Constant()后强行编译成查询（极少见但存在）
这些操作在 .NET 8 中依然存在，且编译器不会报错 —— 它们看起来像 LINQ，实则是裸 SQL 的伪装入口。
如何检测项目中残留的注入点
不要靠人工扫代码。在 .NET 8 项目中，优先用以下方式定位风险调用：
- 全局搜索
FromSqlRaw、FromSqlInterpolated（注意后者虽支持插值，但仅限$"..."中的变量，不能插表名）、ExecuteSqlRaw、ExecuteSqlInterpolated、ExecuteQuery、ExecuteCommand - 对每个匹配结果检查：是否对任何用户输入（
Request.Query、FromBody、RouteData等）做了字符串拼接 - 特别关注动态构建
ORDER BY或WHERE子句的逻辑 —— 有人会写"ORDER BY " + sortField，这是典型漏洞 - 用 Roslyn 分析器（如
Microsoft.CodeAnalysis.NetAnalyzers）配合自定义规则，拦截含"+" + ... + "FROM"模式的字符串拼接
注意：FromSqlInterpolated 是安全的，但仅当写成 $"SELECT * FROM Users WHERE Name = {name}" —— 大括号内必须是纯变量，不能是 {GetSortClause(userInput)} 这类函数调用。
修复建议：替换方案与硬性约束
对已发现的拼接点，按优先级替换：
- 表名/列名动态化 → 改用白名单校验：
if (!new[] { "Users", "Orders" }.Contains(tableName)) throw new InvalidOperationException(); - 排序字段 → 映射到枚举或字典：
var orderMap = new Dictionary<string expression object>>> { ["name"] = u => u.Name, ["age"] = u => u.Age };</string> - 复杂
WHERE条件 → 用ExpressionVisitor动态构建表达式树，而非拼 SQL - 完全无法避免原生 SQL 的场景 → 强制使用
FromSqlInterpolated并确保所有外部输入都在{}内；禁用FromSqlRaw，CI 流程中加入正则扫描（如匹配FromSqlRaw\([^)]*["']\+.*["']\)）
最易被忽略的一点：FromSqlInterpolated 不保护注释和空格控制 —— 如果你允许用户输入 name 为 admin' -- ，虽然不会注入，但可能干扰日志或监控解析。所以仍需基础输入清洗（如 Trim、长度限制），这不是防注入，而是防扰动。
