参数化查询是唯一可靠的SQL注入防线，其他如关键词过滤均为临时补丁；必须用@param占位符配合SqlParameter或FromSqlRaw，禁用字符串拼接、AddWithValue及FromSqlInterpolated，动态对象名需白名单校验，拦截须在模型绑定后、控制器执行前完成。

参数化查询是唯一可靠防线，其他都是补丁

别指望关键词过滤能拦住SQL注入——admin'--、%27OR%201%3D1、/*这些绕过手段太常见。真正起作用的只有参数化查询：用@param占位符 + SqlParameter或EF Core的FromSqlRaw(sql, params)。所有没迁移到这一步的代码，哪怕加了10层关键词检测，都等于没防。

常见错误现象：

• 在string.Format或$"SELECT * FROM {table}"里拼接表名/列名——参数化对此完全无效
• 用AddWithValue传null导致类型推断错误，某些驱动会退化为字符串拼接
• 在Stored Procedure调用中仍用string.Concat拼接WHERE条件

实操建议：

• 强制所有SqlCommand构造必须带Parameters.Add()，禁用AddWithValue
• EF Core中禁用FromSqlInterpolated，只用FromSqlRaw配合显式参数数组
• 对动态表名/排序字段，用白名单硬编码：new[] { "name", "email", "created_at" }.Contains(input)

全局过滤器只能查已绑定参数，别碰原始请求流

在OnActionExecuting里直接读HttpContext.Request.Body或Form会消耗流，导致后续Controller收不到JSON数据——这是静默失败，不是报错。

正确做法是优先从context.ActionArguments取值，它已是模型绑定后的干净对象。如果必须检查原始Query字符串，用context.HttpContext.Request.QueryString.Value；检查POST Body前，先调context.HttpContext.Request.EnableBuffering()再重置Position = 0。

还要跳过ASP.NET内置字段：__RequestVerificationToken、__viewstate（大小写不敏感），它们合法含'或--，误杀会导致登录失败。

关键词检测必须解码+词边界+注释符覆盖

不WebUtility.UrlDecode()和WebUtility.HtmlDecode()就匹配，等于开门揖盗。%27（单引号）、%6f%72（or）会直接漏过。

正则必须加\b词边界，否则"Select"昵称、"union_all"字段名全被误杀。关键词列表至少包含：select、union、drop、exec、xp_cmdshell、--、/*、#——漏掉任一注释符，admin'--就能逃逸。

注意：这种检测只适合临时补丁，且必须配合日志记录（记录原始参数+IP+路径），不能替代参数化。

验证时机错了，整个拦截就失效

在catch (Exception e)里判断是不是SQL注入？晚了。此时SQL可能已执行，数据已泄露，甚至DROP TABLE已完成。

有效拦截点只有一个：模型绑定完成、控制器方法执行前。Minimal API用Validator.TryValidateObject；Controller启用[ApiController]特性让框架自动校验[FromBody]和[FromQuery]参数并返回400。

复杂场景需运行时参数驱动规则：

• 公网IP请求才启用sqlPattern扫描，内网跳过
• /api/v1/report/export接口对keyword额外模拟SQL WHERE子句环境校验
• 管理员提交的script字段启用AST解析，拒绝任何含函数调用的JS表达式

真正该花时间盯的，不是写了多少关键词，而是确认每个string.Format拼接点是否已清理干净——漏一个，全局过滤器就是摆设。