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

　　去年六月份那阵子，我原以为把参数过滤加预编译都怼上就稳了——结果业务方一个“临时需求”直接给我干懵了。那天凌晨三点，运维在群里甩了张监控图，数据库连接池直接爆满，我盯着屏幕上的慢查询日志，心跳都快停了——全是带`UNION SELECT`的畸形语句，可WAF日志里居然没报一条攻击！后来才知道，攻击者绕过前端校验后，直接往某个隐藏字段里灌了payload，预编译那层根本没触发。

　　第一反应是骂娘：业务方非说“用户要传富文本”，把`htmlspecialchars`和`PDO::prepare`全给拆了。我冲进会议室时，他们还在扯“测试环境没问题”——可测试环境哪来的真实流量？我抓着他们的键盘敲了十分钟，把攻击流量里的`CONCAT(0x7e,(SELECT...))`怼到他们脸上，开发主管才挠着头说“哦，可能漏了几个接口”。

　　其实那会儿我最慌的不是被注入，是怕被老板骂。上周刚跟他说“防御体系升级了”，结果转头就被打脸。手机一直在震，是安全部的群在@我：“某IP半小时内扫了三百个接口”“慢查询日志里出现`information_schema`”。我蹲在机房角落啃冷掉的泡面，突然想起三年前那回——当时也是预编译没覆盖全，被拖了十万条用户数据，最后写检查时手都在抖。

　　后来熬了一整夜，把三层防御重新捋了一遍。第一层是参数校验，我直接把所有用户输入都当恶意数据处理，连`int`类型都先用`is_numeric`筛一遍——业务方说“这样会影响用户体验”，我直接怼回去：“被拖库的时候用户体验更差。”第二层是预编译，这次我盯着开发把所有SQL都改成了带参数绑定的，连`ORDER BY`后面的字段名都用白名单卡死——有个老接口非要用动态排序，我直接给它关了，让业务方自己写存储过程。

　　第三层最狠，是数据库权限隔离。我把应用账号的权限砍到只剩`SELECT/INSERT/UPDATE/DELETE`，连`SHOW TABLES`都不给——运维当时就炸了：“这样备份脚本会报错！”我拍着桌子说：“报错总比被拖库强！”其实我心里也没底，毕竟之前没这么干过，可那会儿已经顾不上那么多了。来回折腾三趟，终于把权限收干净，结果第二天业务方又找过来：“某些报表查不了了！”我直接把SQL日志甩给他们：“自己看，都是`SELECT FROM`这种烂写法，改不了就别查。”

　　窗外天亮了，我盯着监控图上的连接数终于降下来，突然想起个事儿——攻击者是怎么绕过WAF的？我翻出日志仔细看，发现他们用了`CHR(117)||CHR(110)||CHR(105)||CHR(111)||CHR(110)`这种拼接方式，WAF只认`UNION`关键字，根本没检测到。我原以为WAF能拦住所有注入，结果它连这种基础变形都防不住——后来我直接把WAF规则库换了，自己写了二十多条正则，专门盯这种字符拼接和十六进制编码。

文章配图，仅供参考

　　不过话说回来，这世上哪有绝对安全的系统？我上周还看到个新闻，说某大厂的预编译都被绕过了——他们用的是某开源框架，结果框架本身有个漏洞，能把参数绑定给绕掉。我现在每天都会随机抽几个接口，用`sleep(5)`这种时间盲注测一遍，生怕哪天又被钻了空子。手机又在震，是运维说某台数据库的CPU突然飙到90%——我叹了口气，抓起键盘往机房跑——这破事儿，估计还得折腾一阵子。

（编辑：站长网）

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