PHP防SQL注入：9年运维总结的3层硬核防御体系

去年10月份，我接手了一个日均百万级流量的电商系统——PHP写的，老代码，漏洞多到能编成一本《SQL注入大全》。最夸张的一次，攻击者直接通过订单页面的`product_id`参数注入，删掉了测试环境里30%的订单数据。这让我意识到：单靠预处理语句（PDO/mysqli）这种“基础防御”，根本扛不住现代自动化攻击工具的狂轰滥炸。

9年运维下来，我总结了一套“3层硬核防御体系”，核心就一个字——新。不是堆砌老技术，而是用新技术覆盖SQL注入的每个攻击链路。第一层是“输入层防御”，用PHP 8.1+的`filter_var()`配合自定义正则——比如手机号参数必须匹配`/^1[3-9]\d{9}$/`，IP地址必须通过`FILTER_VALIDATE_IP`，连用户输入的“昵称”都要过滤掉`( )'`这些特殊字符。去年处理过一个案例：攻击者用`admin'--`绕过登录，结果被正则直接拦截，连数据库都没碰到。

文章配图，仅供参考

第三层是“数据库层防御”——这才是真正的“硬核”。我用了两个新技术：一是MySQL 8.0+的`SQL_MODE=STRICT_TRANS_TABLES`，开启严格模式后，任何非法数据（比如字符串往INT字段插）都会直接报错，而不是默默截断或转换；二是RASP（运行时应用自我保护）工具，比如OpenRASP，它能实时监控SQL语句的执行，发现可疑操作（比如`UNION SELECT`、`SLEEP()`）直接阻断。去年10月那次攻击，攻击者用了`BENCHMARK(1000000,MD5(1))`这种延时注入，结果被RASP在0.1秒内识别并拦截，连日志都没留下。

但新技术也有坑——比如PDO的`quote()`方法，很多人以为它能防注入，其实它只是转义字符串，对数字型注入完全无效。我见过一个失败案例：开发者用`$pdo->quote($_GET['id'])`处理ID参数，结果攻击者传`1 OR 1=1`，直接绕过。还有，RASP工具可能会误报——比如某些合法的批量插入语句，因为包含`UNION`关键字被拦截，这时候需要调整规则，但调整规则又可能降低安全性，这中间的平衡点很难把握。

主观判断：这套3层体系，比传统的“预处理+过滤”强在哪？强在“主动防御”——不是等攻击发生后再拦截，而是在攻击链的每个环节都设卡。输入层过滤掉90%的垃圾数据，参数层用预处理堵住剩下的10%，数据库层用严格模式和RASP做最后兜底。去年10月到现在，这套体系在我负责的5个系统里跑了8个月，0次成功注入——这数据够硬核了吧？

下一步行动？我打算把RASP的规则再细化——比如针对电商系统的“订单查询”接口，单独写一套更严格的SQL监控规则，毕竟高价值接口更容易被盯上。至于局限——这套体系对老代码改造成本高，尤其是那些用`mysql_`函数写的“古董”代码，可能需要重写。但话说回来，都2024年了，谁还在用`mysql_`？

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!