目录遍历漏洞，目录说白了就是遍历攻击者通过构造`../`这样的路径序列，跳出Web应用预设的漏洞目录范围，直接读取服务器上的修复任意文件。去年我帮一家电商公司做渗透测试，建议对方一个图片上传接口就存在这种问题——攻击者只需把请求中的目录`filename`参数改成`../../../../etc/passwd`，就能拿到系统用户列表。遍历更离谱的漏洞是，那套系统居然还跑着root权限的修复Nginx。

修复这件事，建议第一原则永远是目录“默认拒绝”。别指望靠过滤黑名单来挡，遍历`../`的漏洞编码变体太多了——URL编码的`%2e%2e%2f`、双编码的修复`%252e%252e%252f`、甚至用Unicode字符混淆的建议写法，黑名单永远防不全。正确做法是，在代码层面把用户输入的文件路径规范化，比如Python里用`os.path.realpath()`，Java里用`File.getCanonicalPath()`，然后检查解析后的绝对路径是否以你预设的基目录开头。不是的话，直接返回403。这个逻辑应该写在所有文件操作的最前端，不分功能模块。

光有路径校验还不够。我见过不少开发者觉得自己校验写得天衣无缝，结果疏忽了Web服务器的配置层。比如Apache和Nginx的别名配置（`Alias`指令）如果写得不严谨，攻击者可能绕过应用层直接打服务器。建议在服务器配置里禁用跟随符号链接，并确保DocumentRoot指向的目录没有上级目录的读写权限。另外，如果业务上确实需要提供文件下载功能，别让用户直接传路径参数，改成传一个文件ID，后端通过数据库映射找到真实路径。这个方案能根治绝大多数目录遍历问题，代价只是多一次查询而已。

还有个小细节容易被忽略——错误信息泄露。当攻击者尝试读取不存在的文件时，你的应用如果返回“文件不存在于/var/www/html/uploads/”，那就等于免费送情报。统一返回模糊错误，比如“请求无效”，别附带任何路径细节。日志里倒是要记全，方便事后审计。

最后说个实战中很常见的坑：有些系统用Java的`getCanonicalPath()`做了校验，但后续实际读取文件时又用了原始用户输入，而不是校验后的规范化路径。这就等于白校验。务必确保整个流程中，后续所有文件操作都基于那个“已确认安全”的路径变量，而不是重新拼接用户输入。代码评审时盯着这条线查，能揪出不少问题。

目录遍历的修复不是什么高深技术，难的是每个环节都做到位。一次渗透测试的经验告诉我，十个漏洞里有八个是“知道该做什么但没做彻底”。把默认拒绝、路径规范化、服务端配置、错误信息处理这四件事串成一条完整的防线，再配合代码审查，基本就能堵死这个口子。