上个月我们内部做了一次安全扫描，漏洞结果出来后，整改一个老系统的报告步计文件上传接口被标了高危。问题不复杂——前端只做了后缀名白名单，划和后端拿到文件后直接存盘，措施路径拼接用的漏洞是原始文件名。攻击者构造一个带../的整改路径就能覆盖任意目录下的文件。这个漏洞三年前就有人提过，报告步计但因为系统一直跑在内网，划和优先级被压下去了。措施这次不一样，漏洞扫描报告直接抄送了管理层，整改当天下午就开了整改会。报告步计

整改的划和第一步不是写代码，是措施确认影响面。我们翻了近半年的访问日志，发现这个接口每天调用量不到两百次，主要来自两个内部工具。没有外部IP访问记录，暂时排除了已被利用的可能。但日志只保留90天，再往前查不到了。安全组的人说，这种情况得按最坏情况打算——假设漏洞曾被利用过，得检查服务器上有没有异常文件写入。于是运维拉了一份最近半年的文件变更清单，人工筛了一遍，发现三个可疑路径，最后确认是测试环境遗留的临时文件，虚惊一场。

修复方案讨论了两轮。第一轮有人提议直接上WAF规则拦截，被否了——WAF只能挡已知攻击模式，路径穿越的变种太多，治标不治本。第二轮定下来改代码，具体做三件事：文件名用UUID重新生成，不保留任何用户输入；存储路径改成固定目录加日期子目录，拼接前做一次realpath校验；上传接口增加文件类型二次验证，不只看后缀，还要读文件头魔数。代码改动量不大，半天就提交了。但测试花了整整两天——测试同学构造了三十多种畸形文件名，包括空字节截断、双重编码、超长路径，确认全部被拦截才放行。

上线安排在周五凌晨。运维提前做了数据库快照和代码回滚包，结果部署完第一次验证就发现问题：新逻辑对中文文件名处理有bug，realpath返回false。排查发现是编码问题，文件系统用的UTF-8，但接口传过来的文件名被容器环境转成了GBK。临时加了一层编码转换，重新部署，凌晨三点才搞定。这件事让我意识到，安全修复本身不难，难的是兼容旧环境的各种历史包袱。

漏洞修完不等于事情结束。我们定了几条后续措施，都是能落地的。第一，把这个接口加入监控，任何异常文件写入操作实时告警，阈值设得很低，一天超过三次就触发。第二，下个月做一次全量代码审计，重点查其他文件操作相关接口，已经排了四个疑似点。第三，把安全扫描从季度改成月度，扫描结果直接同步到项目管理工具，每个漏洞必须指定修复人和截止时间，逾期自动升级。第四，开发团队内部做一次安全编码培训，不讲理论，就拿这次漏洞当案例，现场写代码演示攻击和防御。

还有一个事我觉得比技术措施更重要。这次漏洞暴露出来的根本问题不是代码水平，是流程缺失——三年前就发现的问题，为什么一直没修？因为没有强制闭环。扫描报告发出来，大家看一眼，觉得内网没事就搁置了。现在我们在项目管理工具里加了一条硬规则：所有安全漏洞必须关联到一个具体的修复任务，任务不关闭，对应的需求就不能上线。这招有点狠，但有效。上周又扫出两个中危漏洞，当天就有人认领了。

漏洞整改这事，最怕的就是修完就忘。我见过太多团队，每次都是出了事紧急补，补完继续裸奔。这次我们多走了一步——把修复过程里用到的检查脚本、测试用例、部署步骤全部整理成文档，放进内部知识库。下次再遇到类似问题，不用从头讨论，直接照着做就行。安全这玩意，靠人盯人迟早出事，得靠流程和工具兜底。