安全漏洞修复及自查

去年冬天，安全一个做电商的漏洞朋友半夜给我打电话，说服务器被挂马了。修复攻击者没偷数据，及自也没删库，安全只是漏洞把首页轮播图换成了赌博广告。他查了两天，修复最后发现漏洞出在一个三年前上线的及自促销插件里——那个插件调用了某个已废弃的第三方库，而那个库存在反序列化漏洞。安全三年里，漏洞没人动过这段代码，修复也没人记得它的及自存在。

这件事让我意识到，安全安全漏洞修复最麻烦的漏洞地方，往往不是修复漏洞本身，而是“谁还记得这东西”。代码一旦上线，就像扔进仓库的纸箱，越堆越高，越久越没人翻。攻击者却喜欢翻旧账。他们不关心你的业务逻辑，只关心哪里能进去。一个废弃的接口、一个忘了删的测试账号、一个没来得及更新的依赖，都可能成为入口。

修复漏洞，第一步不是急着打补丁，而是先搞清楚“这个漏洞是怎么进来的”。很多团队一发现漏洞，立刻升级版本、加WAF规则、重启服务，然后松一口气。但如果不追溯来源，同样的问题还会以另一种形式出现。比如，某次SQL注入是因为拼接了用户输入，那就要问：为什么代码规范里禁止拼接，但实际开发中还是有人这么写？是规范没落地，还是代码审查没覆盖到？

我见过一个团队，每次修复漏洞都只改表面。注入点过滤了，但没改数据库权限；XSS转义了，但没加CSP。结果三个月后，同一个系统换了另一个参数，又被打穿。修复不是贴创可贴，是找到出血点，然后决定是缝合还是截肢。

自查这件事，比修复更考验人。修复有明确目标——把洞堵上。自查没有边界，你得假设自己就是攻击者，然后问：如果我要进这个系统，会从哪里下手？

我的习惯是，先看“入口清单”。所有对外暴露的端口、接口、页面、文件上传点、第三方回调地址，列出来，一个一个过。不是看代码写得好不好，而是看“如果我是攻击者，这里能不能传进奇怪的东西”。比如一个查询接口，参数是订单号，正常是数字，但如果传个字符串进去，后端会怎么处理？报错信息会不会泄露数据库结构？

再看“权限边界”。很多漏洞不是技术问题，是逻辑问题。比如一个普通用户，能不能通过改URL里的ID，看到别人的订单？能不能通过修改请求体里的角色字段，把自己变成管理员？这些不是靠扫描器能扫出来的，得靠人手动测。

还有“依赖清单”。开源组件是双刃剑。用得好，省时间；用不好，就是给自己埋雷。我现在的做法是，每个项目上线前，必须有一份依赖清单，标注版本号、来源、最后更新时间。每季度过一遍，看有没有已知漏洞，有没有停止维护的库。如果某个库已经两年没更新，又不在关键路径上，能换就换，不能换就隔离。

修复和自查，说到底是一种习惯。不是等出了事才做，而是日常开发的一部分。就像出门前检查钥匙、手机、钱包，不是因为你今天一定会丢东西，而是因为丢了很麻烦。安全也一样，麻烦的不是修，是修的时候发现“根本不知道从哪修起”。

那个电商朋友后来把插件删了，重新写了一个简单的轮播组件。他说，早该这么干。三年前为了省两天工期，现在花了三周擦屁股。这笔账，怎么算都不划算。