PHP安全编码三大致命坑：物联网老炮儿的血泪警告

文章配图，仅供参考

　　第二个坑是反序列化，这事儿更离谱。有天早上，运维说服务器磁盘满了，我上去一看，/tmp下多了三百多个.php文件，全是“eval($_POST[a])”这种webshell。溯源的时候发现，攻击者通过设备上报的JSON数据里塞了个O:8:"stdClass":1:{s:3:"cmd";s:10:"system('id');";}，而我们的代码里有个“unserialize($data['payload'])”——我原以为只有用户输入才需要过滤，结果设备上报的数据也能被篡改。更搞笑的是，WAF规则里明明有“检测O:”开头的字符串，但攻击者把payload拆成了十六进制，WAF直接放行。后来查日志，发现攻击IP是185.143.223.172，眼熟得很——上个月刚在另一个项目里见过这IP扫SQL注入，当时没当回事，现在看，人家是“广撒网，多敛鱼”。

　　第三个坑是命令注入，这事儿直接让我怀疑人生。我们有个设备管理接口，接收设备ID和操作类型，代码里是“system("reboot {$device_id}")”。我原以为设备ID是数字，结果攻击者传了个“1; rm -rf /”，直接把设备模拟器的根目录删了。最气人的是，这接口在测试环境跑了半年没事——因为测试环境的设备ID是固定的123，而生产环境是从数据库读的，数据库里被人塞了恶意数据。后来查日志，发现攻击者先通过反序列化漏洞改了数据库，再通过命令注入删文件，一套组合拳打得我们措手不及。运维说“这锅我不背，是开发没做参数校验”，开发说“这锅我不背，是运维没做输入过滤”，最后老板拍板：“安全是成本不是收入，下次注意。”

　　那天晚上，我在群里吐槽，结果运维老张跳出来说：“你们开发就是太懒，非要用system()，用exec()加参数数组不香吗？”我反手甩了张PHP官方文档截图：“exec()的第二个参数是输出数组，谁TM记得传引用？”老张不说话了，过了一会儿发了个表情包：“下次一定.jpg”。其实我知道，他也没辙——安全这玩意儿，光靠代码写死参数校验没用，得从架构上防，比如设备上报的数据先走消息队列，再由独立服务处理，处理前先做格式校验和签名验证。但老板觉得“这样太复杂，影响上线速度”，最后还是让我们“先修漏洞，再优化架构”。

　　现在看，这三个坑的共同点，都是“我以为没事，结果有事”。变量覆盖我以为register_globals早没人用了，反序列化我以为设备上报的数据可信，命令注入我以为设备ID是数字——可物联网的设备，哪个不是用户可控的？安全不是靠“我觉得”能搞定的，得靠“必须这样”。就像老张说的：“下次一定”没用，得这次就改。可问题是，改一次容易，改十次呢？改一百次呢？老板觉得“安全是成本”，可我觉得，不安全才是最大的成本——比如这次，光恢复数据就花了三天，算上加班费和客户投诉，够买十台新服务器了。

　　对了，那天溯源的时候，我还发现个有意思的事——攻击者用的C2服务器IP，和上个月扫我们SQL注入的IP是同一个段。我原以为这是两个团伙，结果查了下WHOIS，发现注册人都是“John Doe”，邮箱是“no-reply@example.com”——这明显是占坑用的。后来在论坛上问了圈，有人说这是“职业扫洞”的，扫到漏洞就卖，不卖就自己用。我突然觉得，安全这事儿，不光是技术问题，还是个“猫捉老鼠”的游戏——你永远不知道老鼠会从哪个洞钻进来，但你得保证，所有洞都堵得死死的。

　　现在，我们的代码里多了三行注释：“// 禁止register_globals”、“// 禁止反序列化用户输入”、“// 禁止直接拼接命令”——虽然老板觉得“注释没用”，但我觉得，至少下次有人接手的时候，能少踩点坑。至于安全是不是成本？我敢打包票，绝对是——但比成本更贵的，是失陷后的损失。就像老张说的：“下次一定”没用，得这次就改。可问题是，这次改了，下次呢？

（编辑：站长网）

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