必须直接修改数据访问层sql构建逻辑，删除所有字符串拼接where条件的代码，like匹配须用sqlparameter显式指定类型并手动包裹通配符，彻底杜绝sql注入。
必须直接修改数据访问层的 SQL 构建逻辑，不能靠上层过滤、Model Binding 或 ActionFilter 补救。所有字符串拼接生成 WHERE 条件的地方，都是高危点。
定位并重写 DAdmin.GetList 中的 criteria.Condition 拼接
这是最常见、最危险的漏洞入口。你看到的 criteria.Condition += string.Format("and Name like '%{0}%'", name) 这类代码，必须全部删除。
- 参数值要手动包裹通配符：
"%" + name + "%"，而不是塞进 SQL 字符串里写'%{0}%' - LIKE 匹配必须用
SqlParameter，且显式指定类型，例如new SqlParameter("@name", SqlDbType.NVarChar) { Value = "%" + name + "%" } - 如果
criteria.Condition最终被拼进cmd.CommandText，说明整个查询构造机制已不可信，需整体重构
验证 Common.GetPageData 是否真正参数化
很多项目误以为“封装了 DAL”就安全，其实只要底层还用 string.Concat 或 string.Format 拼 SQL，就是裸奔。
- 打开
Common.GetPageData实现，确认是否调用了SqlCommand.Parameters.Add() - 检查是否用
new SqlParameter("@param", value)形式传参，而不是仅cmd.Parameters.AddWithValue("@param", value)（后者类型推断不可靠） - 若发现它把
criteria.Condition当作完整字符串拼进 SQL，那这个分页方法本身就有注入风险，修复优先级高于任何 Controller 层改动
别碰 ActionFilter 做“全局 SQL 过滤”
所谓“拦截所有参数把单引号替换成两个单引号”的 ActionFilter，是伪安全方案，MVC 5 中尤其失效。
- 它对
Request.Form、Request.QueryString等原始输入完全无效，攻击者可绕过 Model Binding 直发请求 - 对嵌套对象、集合类型参数基本不生效
- 可能破坏正常业务：用户搜
O’Reilly会被改成O''Reilly，某些旧版驱动仍会执行
真正的修复只发生在数据访问层——SQL 和参数必须分离，且分离动作必须落在 SqlCommand 执行前的最后一环。任何试图在 Controller、Filter、Model Binder 层“消毒”的做法，都只是给裸奔加了一件薄纱。
