SQL注入防护必须采用参数化查询或协议层中间件，禁用字符串替换、黑名单过滤及已废弃函数；ORDER BY和IN需白名单或动态占位符；业务字段中隐藏的SQL需重新校验或改用JSON存储。
SQL注入过滤不能靠字符串替换
手写 str_replace 或正则去删 '、;、UNION 这类操作，本质是无效的。攻击者用宽字节、编码绕过、注释符分隔、大小写混用就能轻松 bypass。比如 %df%27 在某些 GBK 环境下会吃掉转义符，让单引号“复活”；又比如 SEL/**/ECT 也能绕过简单关键词拦截。
真正有效的过滤必须发生在语义层，而不是字符层。这意味着：要么用参数化查询彻底隔离数据与逻辑，要么用经过充分审计的中间件在协议解析后做策略拦截。
- 不要对用户输入做“黑名单式清洗”，尤其别碰
mysql_real_escape_string（已废弃）或自己实现的escape_sql - 如果必须在应用层做前置过滤（如日志采集、非查询类字段校验），只允许白名单字符集，例如手机号只留
0-9，邮箱用标准格式校验，而非“去掉所有 SQL 关键字” - 注意：任何过滤逻辑都应在参数绑定前完成，否则可能干扰 ORM 或驱动的参数处理流程
优先用数据库驱动原生的参数化查询
绝大多数现代语言的数据库驱动都支持真正的参数化（prepared statement），它把 SQL 结构和数据分开传输，服务端根本不会把参数当 SQL 解析。这才是防注入的底层保障，比任何中间件都可靠。
比如 PHP 的 PDO::prepare、Python 的 cursor.execute("SELECT * FROM user WHERE id = %s", [user_id])、Java 的 PreparedStatement —— 它们不是“语法糖”，是协议级隔离。
- 避免用字符串拼接构造查询，哪怕你刚做过
htmlspecialchars或intval，也不能替代参数化 - 注意
ORDER BY和IN子句无法直接参数化：前者需白名单枚举（如['created_at', 'name']），后者要用占位符动态生成（如WHERE id IN (?, ?, ?)） - 某些 ORM（如 Laravel Eloquent）默认启用预处理，但显式调用
DB::raw()或whereRaw()会退出安全路径，必须人工核对
选用成熟中间件时重点看拦截位置和兼容性
像 sqlmap 这类工具能轻易绕过 WAF 层面的规则匹配，所以真正可用的中间件得插在数据库协议解析之后、执行之前，比如 MySQL 的 audit plugin、PostgreSQL 的 pgaudit，或者代理层如 ProxySQL + 自定义 query rule。
别迷信“带 SQL 防护模块”的通用网关（如某些 API 网关的“SQL 注入检测”开关），它们多数只做 HTTP Body 关键词扫描，对二进制协议、prepared statement payload、存储过程调用完全无效。
- 确认中间件是否支持你用的协议版本（如 MySQL 8.0+ 的 caching_sha2_password 认证可能影响插件加载）
- 检查日志是否记录原始 query string 而非 parsed AST —— 如果只记了
SELECT * FROM t WHERE id = ?，就无法判断实际参数是否恶意 - 性能损耗不可忽略：某些中间件会对每条 query 做 full-parse，高并发下可能成为瓶颈，建议压测对比 QPS 下降幅度
业务字段里藏 SQL 是最常被忽略的雷区
很多团队以为“只对登录、搜索框做了防护就安全了”，结果在用户昵称、商品描述、JSON 配置字段里存了 admin' OR '1'='1 这种字符串，后续被后台导出脚本、报表 SQL 拼接、甚至客服系统模糊查询一读就炸。
这类场景往往不走主业务查询路径，也不触发常规 WAF 规则，但只要存在动态拼接 + 未过滤字段，就是注入温床。
- 所有从数据库读出后再拼进新 SQL 的字段，必须重新校验或强制转义（如用
mysqli_real_escape_string，仅限该连接上下文） - 更稳妥的做法是：这类字段统一走 JSON 字段类型存储，查询时用
JSON_EXTRACT或应用层解析，彻底避开 SQL 上下文 - 定期用 SQL 日志回溯扫描：查出所有含
CONCAT(、+、||拼接字段的查询，人工确认是否引入了不可信源
事情说清了就结束。真正难的不是选中间件，而是厘清哪条 SQL 路径没走参数化、哪个字段从入库到使用之间悄悄变了上下文。
