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

　　去年十月那波攻击，我原以为预处理语句就能扛住——毕竟咱们团队用了三年PDO，结果呢？攻击流量翻三倍那天，监控屏直接卡成PPT，饮水机在旁边咕嘟咕嘟响，运维小哥冲进来时还踢翻了打包台上那卷胶带。后来查日志才发现，攻击者绕过了预处理，专挑LIKE模糊查询的接口怼，参数里塞了十六进制编码的恶意payload，PDO根本没触发参数化查询的机制。

　　这事儿让我重新翻了遍PHP手册——别笑，真有人把预处理当万能药。第一层防御说白了就是参数化查询，但有个坑：动态表名/列名没法用占位符。比如"SELECT FROM $table WHERE id = ?"，这时候$table变量要是没过滤，攻击者直接传"users; DROP TABLE orders--"，PDO照样给你执行。我后来在代码里加了硬编码白名单，所有动态表名必须匹配预设的数组，匹配不上直接抛500错误，鼠标垫卷边了都懒得换新的，就为提醒自己别在这栽跟头。

　　第二层是存储过程，但用过的都知道这玩意儿在PHP里有多别扭。我们当时为了防注入，把所有核心查询都塞进存储过程，结果运维天天骂——每次改个字段名得连数据库带应用一起重启，打包台上的胶带用完了都没人敢去换，怕影响部署流程。更坑的是，有些复杂查询用存储过程反而更慢，有次做促销活动，存储过程版的查询比直接写SQL慢了40%，老板差点把技术总监的键盘给砸了。

　　但说真的，存储过程有个隐藏优势：权限控制。我们可以给应用账号只开放执行特定存储过程的权限，连SELECT/INSERT/UPDATE都不给，直接从数据库层面掐断注入路径。去年双十一前，我们把所有用户相关操作都封装成存储过程，攻击流量再大，数据库日志里连个异常查询都没出现——倒是仓库的卷帘门被风吹得砰砰响，搞得监控室以为有人撬锁。

　　第三层是Web应用防火墙（WAF），这玩意儿属于事后补救。我们用的是开源的ModSecurity，规则库调了三个月才稳定。有次规则写得太激进，把正常搜索词"iPhone 15%"当成了SQL注入，直接给用户返回403，动销率掉了5个点，老板在群里@所有人骂了半小时。后来学乖了，只拦那些明显带"UNION SELECT"、"DROP TABLE"的请求，模糊匹配的规则全关掉——宁可漏杀，不可误杀，毕竟断货的损失比注入大多了。

文章配图，仅供参考

　　这三层防御体系能站住脚，核心就一个词：优胜劣汰。预处理语句解决80%的常规注入，存储过程堵住权限漏洞，WAF补上最后20%的变种攻击。但别以为这样就能高枕无忧——去年有个同行更狠，直接把所有用户输入都转义成HTML实体，结果用户搜索"O'Reilly"时，系统返回的是"O'Reilly"，动销率直接腰斩，老板差点把他开除。

　　跑题说个事：我们仓库有个老哥，总抱怨打包台上的胶带用得太快。后来发现是WAF规则太严，把爬虫都当攻击拦了，导致商品图片加载失败，用户退货率上升，打包台自然就忙了。后来调整了规则，退货率降了，胶带用量也正常了——你说这算不算防御体系的副作用？

　　现在回头看，这三层防御最坑的不是技术，是人的惰性。开发总想用预处理语句一劳永逸，运维觉得存储过程太麻烦，安全团队抱怨WAF误报多——但真出了事，谁也跑不了。去年那波攻击后，我们定了死规矩：所有新接口必须同时过三层检测，否则不许上线。现在代码里到处都是白名单校验、存储过程调用和WAF规则注释，打包台上的胶带也换成了加厚的——虽然贵点，但至少不用天天换。

　　最后说个真事：上周有个刚入职的实习生问我，为什么不用ORM框架防注入？我让他去查查2018年ThinkPHP的远程代码执行漏洞——那事儿就是因为ORM的参数绑定没做好，导致攻击者直接执行系统命令。现在你还觉得ORM是银弹吗？

　　这三层体系不是万能的，但至少能让你在攻击来临时，多撑几分钟。至于能不能彻底防住？反正我们老板现在要求，每月做一次渗透测试，攻击成功一次扣技术团队5000奖金——你说这算不算变相激励？

（编辑：航空爱好网）

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