内容摘要：目录遍历漏洞，说白了就是攻击者利用服务器对文件路径的过滤不严，通过构造特殊字符序列，跳出Web根目录的限制，去读取或执行那些本不该被访问的文件。这个漏洞几乎和Web应用一样古老，但直到今天，它仍然活跃

目录遍历漏洞，目录说白了就是遍历攻击者利用服务器对文件路径的过滤不严，通过构造特殊字符序列，漏洞利用跳出Web根目录的目录限制，去读取或执行那些本不该被访问的遍历文件。这个漏洞几乎和Web应用一样古老，漏洞利用但直到今天，目录它仍然活跃在大量系统里。遍历

一个典型的漏洞利用攻击请求长这样：GET /download?file=../../../../etc/passwd。服务器如果没做校验，目录就会乖乖地把/etc/passwd内容吐出来。遍历更危险的漏洞利用是，如果配合上传功能，目录攻击者可以直接写入一个webshell到服务器任意目录，遍历然后通过目录遍历找到它并执行——一步到位，漏洞利用服务器直接沦陷。

我见过一个真实案例。某家做在线文档预览的公司，用户上传PDF后，系统会调用一个内部服务把PDF转为图片。那个转换服务恰好开了一个调试接口，路径参数没过滤。攻击者通过构造..%2f..%2f..%2fetc%2fshadow，直接读走了Linux的密码哈希。更讽刺的是，那台服务器上还存着所有用户的原始文档——隐私数据全裸奔了。

为什么这个漏洞这么难根除？原因很实际。很多老的代码库是十年前写的，当时的开发者默认Web应用跑在隔离环境里，谁会想到有人能往上跳目录？后来加了安全层，但往往是简单替换../字符串——攻击者换个编码方式就绕过了，比如..%252f（二次URL编码）或者....//（双点加斜杠的变体）。

还有个容易被忽略的坑：Windows系统上的路径分隔符是反斜杠\，Linux是正斜杠/。如果开发者只过滤了正斜杠，攻击者用反斜杠就能绕过。有些框架会自动规范化路径，但如果你自己拼接文件路径，就很容易踩雷。

修复方案其实不难，但需要严格执行。最有效的方式是白名单校验——只允许文件名匹配特定正则，比如^[a-zA-Z0-9_\-]+\.pdf$。其次，使用编程语言提供的安全API，比如Python的os.path.realpath()，把拼接后的路径规范化，然后检查它是否以允许的根目录开头。别自己写字符串替换，那永远是打地鼠。

我见过不少开发者的误区，觉得只要把..替换成空字符串就安全了。结果攻击者传....//，替换后剩../，照样穿越。这种攻防对抗，本质上是黑名单永远斗不过白名单——你永远想不到攻击者下一个编码变体是什么。

说句实话，目录遍历漏洞的检测也比想象中简单。用自动化扫描器跑一遍常见Payload，基本能发现大部分问题。但真正的难点在于那些藏在业务逻辑深处的拼接点——比如文件下载接口里嵌套了另一个内部跳转，或者模板引擎里动态加载了用户可控的路径。这种地方，光靠扫描器扫不出来，得靠代码审计逐行看。

最后提醒一句：别以为内网系统就安全。我见过不少内网工具，管理后台直接暴露在办公网，连个VPN都不加。攻击者只要通过钓鱼进了内网，这些带洞的系统就是他们的提款机。安全这东西，从来不是“我们没被攻击过”就代表安全——而是“就算被攻击了，我也能挡住”。