PHP防SQL注入：三层硬核防御体系

　　去年冬天那回，测试提了个P0阻塞——用户登录接口能直接SQL注入，把数据库表都给删了。我原以为肯定是哪个新人没转义参数，结果翻代码发现，特么连主架构师写的核心查询都漏了预处理。当时会议室里键盘敲得噼里啪啦，老张的机械轴卡了个键帽，弹起来砸在测试机上，屏幕闪了两下直接蓝屏——那台机器的充电线还短，得斜着身子才能插上，复现的时候手都酸了。

　　后来我们蹲在白板前，把所有SQL相关的代码全拉出来，发现防御手段那叫一个五花八门：有人用addslashes，有人手动拼接WHERE条件，还有人直接信任前端传的JSON字段。我说这不行啊，得搞个统一标准，结果小李跳出来说：“预处理性能差，我们之前测过，比直接拼接慢20%。”我当场就炸了——慢20%能比数据库被删更严重？他桌上摆着三台手机，屏幕亮着三个不同版本的APP，说“用户等不起”。

　　后来我们定了三层防御：第一层是框架自带的ORM，强制所有查询必须走预处理；第二层是中间件拦截，对GET/POST参数做二次过滤；第三层是数据库层面设权限，普通用户账号连DROP权限都没有。当时觉得这够硬核了吧？结果灰度上线第一天，监控就报了500错误——有个老接口没改ORM，直接抛了异常，把整个服务打挂了。那会儿外卖都凉透了，测试小姑娘蹲在工位啃冷掉的包子，说“这锅得测试背，用例没覆盖到兼容场景”。

　　我原以为三层防御能覆盖所有边界，结果发现最坑的是那些“偶现”问题。比如有个搜索接口，参数里带空格的时候，预处理和过滤层都放行了，但数据库索引没优化，直接全表扫描——这不算注入，但能把CPU打满。还有次是测试机的时间戳和线上不一致，复现的时候怎么都触发不了防御逻辑，后来发现是时区设置问题，老王蹲在服务器前调了俩小时配置文件，键盘上的F5键都快按秃噜皮了。

　　最绝的是那次漏测。我们自以为把所有SQL相关的接口都标红了，结果有个隐藏的定时任务，用的是十年前的存储过程，里面全是动态拼接的SQL。线上跑了三个月没人发现，直到某天数据量暴增，存储过程执行超时，把整个队列堵死了。那会儿我正在开会，手机震得跟地震似的，一看监控，CPU 100%，内存OOM，赶紧冲回工位杀进程。后来查日志才发现，那存储过程里连最基本的参数校验都没有，传个“1; DROP TABLE users”就能直接执行——三层防御？在那玩意儿面前跟纸糊的似的。

　　后来我们学乖了，防御体系不能光靠“硬核”，得靠“优胜劣汰”。比如ORM强制用，但允许特殊接口申请白名单；中间件过滤默认开，但可以关（得走审批）；数据库权限严格控制，但给每个应用单独账号，出了问题直接溯源。现在测试提单的时候，第一句话先问“这接口走的是哪层防御？”要是三层都过了，优先级直接降成P3——反正出问题也是架构的锅，跟我们测试没关系。

　　不过说真的，这三层防御里最管用的还是数据库权限。去年有个实习生误删了测试库，结果发现他用的账号只有SELECT权限，删表的时候直接报错，连执行机会都没有。要是早这么设，去年冬天那P0阻塞根本不会发生——主架构师写的核心查询漏预处理？没事，他账号没DROP权限，最多把数据查乱，删不了表。

　　现在回头看，那三层防御体系能站住，靠的不是技术多牛，而是“谁出错谁背锅”的规则。ORM不用？可以，但出了注入问题自己写复盘报告；中间件过滤关了？行，但得在提单里标红风险；数据库权限乱设？抱歉，运维直接锁账号，连开发机都登不上去。我们测试现在最轻松——只要看防御层有没有被绕过，至于性能慢20%？那是架构组和产品组吵架的事，跟我们没关系。

文章配图，仅供参考

　　键盘上那个不回弹的键终于换了，但新键帽有点松，敲起来“咔哒咔哒”响。测试机充电线还是短，老张买了个延长线，结果插排不够用，又得找运维申请。白板上那半擦掉的数字是“3.2%”，不知道是昨天的错误率还是今天的覆盖率，反正没人擦，就这么挂着——可能等下次出问题的时候，才会有人想起来去算清楚。

（编辑：站长网）

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