目录穿越漏洞

目录穿越漏洞说白了，目录就是漏洞程序在拼文件路径的时候没管住用户输入，让人用 ../ 这类东西溜出了本该待着的目录目录。听起来像是漏洞上世纪的老毛病，但直到今天，目录它还在各种代码库里反复冒头。漏洞

我最早碰到这个问题，目录是漏洞在一个内部文件下载接口上。URL 长这样：/download?目录file=report.pdf，后端直接拿 file 参数往存储目录上一拼，漏洞读出来就吐给浏览器。目录当时我随手把参数改成 ../../../../etc/passwd，漏洞页面安静了两秒，目录然后整份密码文件就躺在响应体里了。漏洞那种感觉挺微妙的目录——你没用什么高级工具，就敲了几个点和斜杠，服务器就把底裤交出来了。

原理其实一句话能讲完：../ 在文件系统里代表上一级目录，连续叠加就能一直往上跳，直到根目录。程序如果只是简单地把“用户输入”和“基础路径”做字符串拼接，而没有做规范化校验，攻击者就能让最终路径跑到预期范围之外。比如 /var/www/uploads/ 加上 ../../../etc/shadow，解析后变成 /etc/shadow，服务器照读不误。

但实际场景里没这么直白。开发者也不傻，很多人会过滤 ../。于是绕过手法就来了：用 URL 编码 %2e%2e%2f，用双重编码 %252e%252e%252f，或者混入绝对路径 /etc/passwd 直接覆盖拼接结果。还有更阴的——某些框架会自动解码一次，你的过滤器看到的是编码后的字符串，等真正打开文件时已经还原成 ../ 了。这种时间差，光靠正则替换根本挡不住。

Windows 环境另有一套玩法。..\ 反斜杠版本、....// 这种畸形串、甚至利用短文件名 WEB~1.CON，都能绕过粗糙的检查。我见过一个案例，过滤器只删了 ../，攻击者提交 ..././，删除操作把中间的 ../ 拿掉后，剩下的 ../ 正好拼成有效路径。这种“删着删着就对了”的逻辑，写代码的人当时肯定觉得自己挺聪明。

危害不用多说。读配置文件拿到数据库密码，读源码发现更多漏洞，要是碰上文件上传加目录穿越的组合，直接写个 webshell 进去也不是不可能。更麻烦的是，这类漏洞往往藏在辅助功能里——日志查看、模板加载、语言包切换、备份恢复，这些地方安全评审容易漏掉，开发也觉得“就是个内部工具”。

防御的核心就一条：别自己拼路径。用语言自带的路径规范化函数，比如 Python 的 os.path.realpath 加前缀校验，Java 的 Path.normalize()，然后确认结果确实在允许的目录之下。白名单比黑名单可靠，固定文件名映射比动态拼接安全。如果非要接受用户输入，那就只允许字母数字和有限符号，别给点号和斜杠任何机会。

说句实在话，目录穿越漏洞能活这么多年，不是因为它难防，而是因为它太容易写出来了。一行字符串拼接就能跑通功能，谁还会去想 ../ 的事。安全这事儿，往往就是在这种“先跑起来再说”的瞬间被丢到脑后的。

很赞哦!（754）