漏洞如何修复

2021年冬天，漏洞Log4j那个漏洞爆出来的何修时候，我正好在帮一个朋友看他的漏洞小电商站。他慌慌张张打电话说“服务器好像被人挖矿了”，何修我登上去一看，漏洞CPU跑满，何修日志里全是漏洞JNDI注入的痕迹。这玩意儿就是何修后来被叫做“Log4Shell”的东西——一个日志库，平时谁也不会多看一眼，漏洞结果因为一个递归解析的何修疏忽，让攻击者能直接加载远程代码。漏洞

修复它花了不到十分钟。何修改一行配置，漏洞把JNDI的何修远程加载关掉，重启服务。漏洞但前面排查花了两个小时。真正麻烦的从来不是“怎么修”，而是“知道要修什么”。

漏洞修复这件事，大多数人以为是个技术活。其实它更像是一个流程问题。我见过太多团队，补丁打得很勤快，但同一类漏洞反复出现。比如SQL注入，明明用了预编译语句，结果某个新来的开发在报表模块里又拼了个字符串。修了，又破了。问题不在代码，在习惯。

先得有人告诉你哪里有洞。自己扫，用工具，或者等别人来告诉你——后者通常代价更大。我习惯用nuclei跑一遍常见模板，再配合semgrep做静态扫描。工具不贵，贵的是人去看报告。很多小团队买了扫描器，报告堆在邮箱里没人点开。那跟没买一样。

确认漏洞存在之后，第一件事不是立刻改代码。先评估影响面。这个接口有没有暴露在公网？有没有鉴权？数据能不能被拖走？我见过一个案例，某个内部管理后台的XSS漏洞，因为只有内网能访问，团队决定不修，用WAF挡一下了事。这个决定对不对另说，但至少他们想清楚了。最怕的是那种“看到高危就通宵改，改完发现那个服务根本没上线”的。

修复本身往往很简单。升级依赖版本，加一行过滤，改一个配置。但有个坑：你改完得验证。不是跑一下单元测试就完事。要复现攻击路径，确认打不穿了。我习惯写一个最小的PoC，修之前能触发，修之后报错。这样才算闭环。不然你以为修好了，其实只是攻击者换了个编码方式。

还有一点，修复完要记录。不是写那种“已修复”三个字。要写清楚：什么漏洞，影响哪个版本，怎么修的，谁验证的。下次再遇到类似的，翻记录比翻代码快。我自己的笔记里有一条：“2023-04-12，Fastjson 1.2.80，autoType绕过，升级到1.2.83并开启safeMode，验证payload：xxx”。简单，但管用。

最后说个反直觉的：有些漏洞不修比修好。比如一个老系统，依赖了一个十年没更新的库，但那个库的漏洞需要特定条件才能触发，而你的业务根本走不到那条路径。强行升级可能引入兼容性问题，把整个服务搞挂。这时候更合理的做法是加一层网络隔离，或者写个规则挡住利用流量。修漏洞的目标是降低风险，不是追求“零漏洞”的虚荣指标。

Log4j那个朋友后来问我，要不要把所有Java依赖都升级一遍。我说不用，你先把你真正在用的、暴露在外面的那几个服务理清楚。漏洞是修不完的，但你可以让自己不那么容易被盯上。