微服务中二阶注入更难拦截，因恶意数据首次写入即潜伏数据库，经多服务流转后在非前端入口（如定时任务）触发，绕过WAF与日志关联；.NET中string.Format、sp_executesql误用、Dapper模板替换、EF Core字符串插值等易漏防护；须在DB访问层、DTO映射、EF Core拦截器三节点强制参数化。
为什么微服务里二阶注入比单体更难拦住
因为二阶注入的恶意数据在第一次写入时就“埋进”了数据库，而微服务之间调用频繁、数据流转路径分散——比如用户昵称在 UserProfileService 存入 MySQL，之后被 ReportService 读出拼进 GROUP BY 查询，或被 NotificationService 拼进动态 SQL 发送推送。这时 PreparedStatement 在 ReportService 里确实生效，但前提是它真用了参数化；而现实中，很多报表导出、统计聚合类逻辑仍依赖字符串拼接。
更麻烦的是：攻击者根本不需要触发前端入口。他可能只提交一次带 ' OR SLEEP(5)-- 的昵称，等三天后运维跑定时报表任务时才真正执行——这种时间差让日志关联、WAF 规则匹配全部失效。
.NET 中哪些地方最容易漏掉二阶防护
不是所有 SqlCommand 都默认安全。以下场景必须人工确认是否参数化：
- 使用
string.Format或$""拼接 SQL 字符串，哪怕变量来自数据库查询结果 -
sp_executesql调用中，把从 DB 查出的字段直接塞进@sql参数（而非作为独立参数传入） - Dapper 的
Query<t>(sql, param)</t>写法里，param是匿名对象，但 sql 字符串里写了{UserName}这种占位符（这是模板替换，不是参数化） - Entity Framework Core 执行原始 SQL 时用
FromSqlRaw+ 字符串插值，例如context.Users.FromSqlRaw($"SELECT * FROM users WHERE dept = '{deptName}'")
这些写法在单元测试里完全正常，但只要 deptName 来自数据库某张配置表，就构成典型二阶链路。
必须强制参数化的三个关键节点
不能只靠开发自觉。在 .NET 微服务架构中，需在基础设施层卡死：
-
数据库访问层封装：所有
IDbConnection扩展方法（如ExecuteScalarAsync）禁止接受string sql，只允许string sql, object? parameters重载；用编译期约束替代 runtime 提醒 -
DTO 层反序列化拦截：对从数据库查出、即将用于构造新查询的字段（如
UserName,Remark,TemplateContent），在 AutoMapper 或手动映射时加[SqlSafe]特性，并在ValueResolver中做白名单校验（例如仅允许 ASCII 字母数字和下划线） -
EF Core 全局拦截器：注册
IDbCommandInterceptor，在ReaderExecuted后扫描command.CommandText是否含未参数化的变量引用（如WHERE name = 'xxx'），命中即记录告警并标记上下文为可疑
注意：SqlParameter 的 SqlDbType 类型必须显式指定，尤其对 varchar/nvarchar 字段，避免因类型推断失败导致驱动回退到字符串拼接。
网关层无法替代服务内参数化
有人想在 API 网关（如 Ocelot 或 YARP）里统一过滤所有含 UNION SELECT 的请求体——这挡不住二阶注入。因为攻击 payload 不在初始请求里，而在数据库中静默存在。网关看到的只是 GET /report/daily?date=2026-09-30，干净得毫无破绽。
真正要盯紧的是服务间调用链：当 ReportService 调用 UserProfileService.GetBasicInfoAsync(userId) 后，拿到的 UserInfo.Nickname 如果直接拼进 SELECT COUNT(*) FROM logs WHERE user_nickname = '{nickname}'，那就已经失守。这个拼接点，永远在业务代码里，不在网关配置里。
最易被忽略的一点：日志脱敏不等于防注入。把 Nickname 打印成 [REDACTED] 只是掩盖痕迹，不阻止它被当作 SQL 片段执行。
