SQL注入防御技术方案_基于正则表达式的输入清洗

正则清洗不能防SQL注入，因其无法覆盖宽字节、编码混淆、函数嵌套等绕过方式；真正有效的是参数化查询、白名单校验字段名、最小数据库权限。正则清洗不能防SQL注入，别再写了正则表达式做输入清洗，对SQL注入基本无效。它既无法覆盖所有绕过方式，又容易因规则宽松放行恶意载荷、或规则严格误杀合法输入。真实攻击者早就不靠 ' 或 UNION 明文出现来注入了------用宽字节、注释符、编码混淆、函数嵌套，WHERE id = 1 AND (SELECT ...) 这类结构连正则都难识别边界。为什么 preg_replace + 黑名单永远漏报常见做法是用 preg_replace 过滤 SELECT、INSERT、--、/* 等关键词，但问题极多：大小写绕过：SeLeCt、%53%45%4c%45%43%54（URL编码）都不匹配内联注释干扰：SEL/**/ECT、SELEC/*abc*/T 拆开关键词仍可执行空格非必须：SELECT(id)FROM 在 MySQL 中合法，且无空格就逃过空格依赖型正则函数嵌套绕过：EXTRACTVALUE(1,CONCAT(0x7e,(SELECT ...))) 里没有一个关键词在黑名单中真正该用的三件事：参数化 + 白名单 + 最小权限防御SQL注入只有三条硬路，缺一不可：所有动态拼接的查询，必须用 mysqli_prepare 或 PDO::prepare + bind_param，变量进 ? 占位符，数据库引擎自动隔离语义若必须拼接表名/字段名（如动态排序），只允许从预定义白名单中取值：valid_fields = \['name', 'created_at', 'status'\];，用 in_array(input, $valid_fields, true) 校验数据库连接账号去掉 FILE、PROCESS、GRANT OPTION 等高危权限，限制只能查指定库表正则唯一能用的场景：格式校验，不是防注入正则可以且应该用在「输入是否符合业务格式」上，和SQL安全无关： RedClaw 百度推出的手机端万能AI Agent助手