PHP防SQL注入：14年经验总结的3层硬核防御体系

　　凌晨三点半，告警群炸了——三台业务机的SQL注入告警同时弹窗，我盯着屏幕上的`SELECT FROM users WHERE username='${_GET['id']}'`，泡面汤溅在键盘上都没察觉。机房空调吹得后颈发凉，开发老张的电话跟着打进来，背景音里还有他媳妇骂他“又熬夜”的吼声。这场景我十四年见了不下二十回，可每次还是心跳加速——防SQL注入这事儿，真他妈像在走钢丝。

　　我原以为预处理语句+参数绑定早成行业标配了，结果上周扫代码库，发现新上线的支付模块还在用`mysql_query()`拼字符串。开发小李振振有词：“就三个字段，手动转义更快！”我直接把测试机的日志甩他脸上——昨天刚被扫出三个高危注入点，攻击者用的还是十年前的`sleep()`延时盲注。其实参数化查询这事儿，2010年我就在博客园写过文章，可到现在还有人觉得“我转义了单引号就安全”，跟他们吵起来比修机房断电还累。

　　但话说回来，光靠开发自觉肯定不行。2025年七月那次大事故，就是吃了这个亏——攻击者用`UNION SELECT`把整个用户表导出来了，我们查了三天才发现是某个遗留系统的`addslashes()`漏了GBK编码的漏洞。从那以后，我硬是在Nginx层加了WAF，规则库每周更新，黑名单里现在攒了三千多条变种payload。上周还拦了个用`//`注释绕过空格的，要没这层防御，开发那帮人得连夜改代码。

　　可光有WAF也不够。上个月迁移数据库，我特意把所有`INT`类型的字段加了严格类型检查，结果测试环境报错——原来有个十年前的订单查询接口，前端传的是字符串“123”，后端直接拼进SQL了。开发老王挠着头说：“这接口用了十三年，从来没出过问题啊！”我盯着他冷笑：“没出问题是因为没人试，现在攻击者会专门测这种边缘情况。”最后我们改了接口参数类型，还在存储过程里加了`CAST(... AS SIGNED)`，这才算堵住这个窟窿。

文章配图，仅供参考

　　但话说回来，这十四年干下来，我倒觉得“优胜劣汰”这四个字特别准。那些靠“我觉得安全”写代码的团队，早就被攻击者教做人了；活下来的，要么是严格用预处理语句，要么是WAF+类型检查+代码审计三重防护。就像上周那个新来的实习生，问我“为什么不用正则表达式过滤输入”，我直接把他带到监控室，指着满屏的`1' OR '1'='1`说：“这些变种，你写一百条正则也防不住。”

　　窗外天快亮了，告警群终于安静下来。我揉着发红的眼睛，把今天要补的防御措施列了个清单：给所有存储过程加`STRICT_TRANS_TABLES`模式，把WAF的规则库同步到测试环境，再找开发开次会——这次得把CTO也拉上，光靠技术说服不了那帮人。其实我知道，SQL注入这事儿永远防不完，但至少，别让十四年的经验白攒。

（编辑：站长网）

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