目录遍历漏洞这玩意儿，目录看着简单，遍历杀伤力却往往被低估。漏洞我见过太多团队，整改修完代码就以为万事大吉，目录结果被绕过WAF的遍历编码变种打了个措手不及。今天不说空话，漏洞直接拆解一次真实的整改整改过程——某政务系统，攻击者用../../etc/passwd读到系统文件，目录日志里全是遍历半截路径，吓得运维连夜打电话。漏洞

当时第一反应是整改加过滤，正则匹配..和斜杠。目录但这么干等于给攻击者出考题——URL编码、遍历双重编码、漏洞Unicode畸形序列，哪个不能绕过？光靠黑名单是堵不住的，得从根上改。我们把整改拆成三层：代码层、配置层、架构层。代码层不是简单拦参数，而是重写文件访问逻辑。凡涉及文件路径的操作，一律用白名单映射，把用户输入的相对路径转成内部ID，再查表拿真实路径。这招狠，直接断了路径拼接的念想。

配置层更实在。Web服务器和中间件里，关掉不必要的目录别名，禁用FollowSymLinks，限制脚本执行权限。有个细节很多人忽略：临时目录的写权限。攻击者常利用/tmp或上传目录做跳板，我们直接把上传目录的脚本执行权限给掐了，用Nginx的location规则单独隔离。你猜怎么着？光是这一条，就挡掉了后续模拟攻击里六成的尝试。

架构层才是真正的护城河。把静态资源挪到对象存储，应用服务器只保留必要文件，并开启chroot或容器隔离。说白了，就算代码漏洞没堵死，攻击者拿到路径也只能在沙箱里打转。有个运维同事出了个馊主意——把关键目录的权限改成000，结果直接把服务搞挂了。后来才明白，权限控制要配合用户分组，别一刀切。

整改完别急着收工。复测阶段我们专门写了个小脚本，循环发送畸形请求，从%2e%2e%2f到..%252f，盯着响应状态码和日志变化。发现一个隐蔽问题：某些框架自带的静态文件处理器，居然对;后的路径不校验。这提醒我，修补漏洞不能只看业务代码，框架和依赖库的版本也得查。那次之后，我们把组件扫描加进了CI流水线，每次构建自动检查已知CVE。

说句实在话，目录遍历往往不是独立存在的。它常跟文件包含、任意文件读取混在一起。修的时候别只盯着一个点，得顺着数据流捋一遍——参数从哪进、往哪去、经过哪些函数。我们那次就顺藤摸瓜，发现另一个接口存在file_get_contents的滥用，一并改了。

最后留个观察：很多整改报告写得漂亮，但代码评审时才发现，过滤逻辑全堆在Controller入口，底层公共函数还是裸奔。建议把校验下沉到工具类或中间件，统一出口。毕竟，安全不是某个人的英雄主义，是系统性的习惯。你堵住了一百个洞，第一百零一个可能就在你忽略的第三方插件里。