PHP防注入？9年经验揭秘：3层防御90%人栽了

　　去年中秋，我跟外包组的几个兄弟蹲在机房临时拉的折叠桌前，啃着外卖盒盯线上告警——不是服务器炸了，是业务后台突然冒出来一堆乱改的用户评论，连测试环境都没测出来的口子，愣是让个没碰过核心代码的外包实习生撞开了。我原以为用了PDO预处理、过滤特殊字符、加了白名单这三层，就算踩了PHP防注入的坑，结果呢？那实习生根本没走注入流程，他是拿了我写的公共函数，函数里的过滤规则留了个小口子，专门绕了单引号的转义，直接用union拼了个查询，连注释都没加。

　　冷眼说的就是我当时的状态，盯着屏幕上的乱码评论，连外卖都没胃口吃。我们这三层防御，是之前踩过某电商平台的注入坑后攒的：预处理防单引号，过滤单引号和union关键字，白名单只允许指定的几个表名。9年里碰过的注入，少说也有小两百起，之前都能兜住，怎么这一次就栽了？更气人的是，这实习生还跟我掰扯，说他查了文档，过滤函数里的正则只匹配了闭合的单引号，没管开头的，他把注释的--换成了/，直接绕过去了。

　　我跟这几个外包兄弟是下午三点到的机房，当时告警刚弹出来。负责人在电话里骂了半小时，说他上周刚给全员发了防注入的培训，怎么还有人敢这么干。我们先查服务器日志，没看到恶意请求的痕迹，直到拉了公共函数的调用记录，才发现那实习生用的是我三个月前写的、用来处理用户输入的过滤函数——我当时为了省事，只加了单引号的转义，没加对/的匹配，他就抓着这个漏洞钻了空子。

　　哪年我还碰过更离谱的？某教育平台的后台，用的是同样的过滤规则，结果被人用了ASCII码编码后的union，把关键字换成了十六进制，过滤函数直接没认出来。那次花了三天三夜补的规则，这次居然被个实习生用简单的注释就破了，我原以为靠规则堆厚度就能防住，结果连最基本的上下文校验都没做——那函数是处理评论的，评论里根本不需要查用户表，我居然没在函数里加表名的白名单，光靠过滤关键字顶个屁用。

　　几个碎片拼起来的细节，我现在还记得很清楚：实习生的操作记录里，那个union查询的表名是user，他没改任何代码，只是把注释从--换成了/，就绕开了我写的过滤规则。我们把那函数改了三遍才兜住，第一遍是加了对/的匹配，第二遍是给公共函数加了调用者校验，第三遍是把预处理的代码直接嵌进了处理逻辑里，不让公共函数单独用。

　　跟外包兄弟蹲在机房的时候，我还差点跟人吵起来。有个兄弟说这事儿不能全怪实习生，是我写的函数有漏洞，培训也没跟上——我们确实上周才发了培训，但是培训内容只讲了预处理和过滤，没讲怎么检查函数的上下文。还有个兄弟说，那实习生是个大二的兼职，只会用现成的代码，根本没意识到自己的操作会有风险。我当时怼了他一句，说就是因为有这种只会用现成代码的人，才会有90%的人栽在这种三层防御上。

文章配图，仅供参考

　　写到这儿我突然想跑题插一句——上次我把类似的规则给了一个做社区的朋友，他说他的代码里连过滤都没做，直接用了框架自带的预处理，结果从来没出过注入问题。我当时还笑他懒，现在想想，人家才是真的懂防注入，根本不会搞这些花里胡哨的三层防御，就用最基础的框架自带功能。

　　后来我们把这次的漏洞整理成了文档，但是没敢发给全组，怕大家觉得我之前的工作没做到位。还是自己改了公共函数，把所有可能绕开过滤的情况都补上了。这事儿其实也没什么大不了的，就是9年里碰过的最扯淡的一个注入坑——不是什么高难度的绕过，就是我自己写的函数留了个小口子，被个实习生轻易撞开了。

　　我原以为防注入的三层防御是保险的，结果栽在了最基础的细节上。后来我跟几个同行聊起这事儿，才发现好多人都跟我一样，以为堆了三层规则就够了，结果栽在各种意想不到的地方——比如字符编码的问题，比如数据库配置的问题，比如函数上下文的问题。优胜劣汰这话真没错，那些只看表面三层防御的人，早晚得栽，能真正理解防注入本质的人，才不会掉坑里。

　　现在我写代码的时候，再也不会随便写公共函数了。每次写过滤规则，都会先想清楚这个函数是干什么用的，有没有必要加表名白名单，有没有可能被绕开。还有那个实习生，我后来跟他聊了几句，他说他只是想测试一下自己写的脚本，没想到真能成功。我跟他说，下次测试之前先跟负责人说一声，别再搞这种乌龙了。

　　最后说一句，别总盯着那些所谓的防御层数，多看看自己写的代码里有没有漏洞，多想想怎么从根本上避免注入，别再被那些花里胡哨的东西忽悠了。毕竟，9年的经验告诉我，最靠谱的防御，从来都不是什么复杂的规则，而是对每一行代码的敬畏。

（编辑：站长网）

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