防止SQL注入的应用层过滤_采用成熟的安全过滤中间件

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。 Trenz AI驱动的社交电商营销平台，专为TikTok Shop设计