2021年，目录某安全团队在渗透测试中发现，遍历一个看似普通的攻击图片下载接口，只需把URL里的目录文件名改成../../../../etc/passwd，服务器就乖乖吐出了系统用户列表。遍历这不是攻击什么高深漏洞，就是目录目录遍历——攻击者用../这种相对路径符号，一层层跳出程序设定的遍历目录边界，去读本来不该碰的攻击文件。

原理简单得有点离谱。目录Web应用通常把用户能访问的遍历文件限制在某个目录里，比如/var/www/uploads/。攻击但代码如果直接把用户输入拼进文件路径，目录没做过滤，遍历那../就成了万能钥匙。攻击../的意思是“上一级目录”，连续写几次，就能从uploads爬到www，再爬到根目录。攻击者不需要什么0day，只要目标程序偷懒，就能得手。

我见过一个真实案例。某小型电商的后台有个“导出日志”功能，参数是filename=access.log。测试时把参数改成filename=../../../../etc/shadow，页面直接返回了密码哈希。开发人员后来解释，他们觉得“日志目录是固定的，用户改不了”。可代码里用的是File.ReadAllText(basePath + filename)，字符串拼接，没有任何路径规范化。这种思维很常见——默认用户会老实输入，忘了攻击者会故意构造。

目录遍历不限于../。Windows系统里..\同样有效，URL编码后%2e%2e%2f能绕过一些粗糙的过滤器。还有绝对路径直接写/etc/passwd，如果程序没限制根目录，照样能读。更隐蔽的是利用符号链接或空字节截断，不过后者在現代语言里基本被堵死了。

防御这事，说难也不难。核心就一条：别信用户输入。具体做法，先把用户提供的路径规范化，用realpath()或GetFullPath()转成绝对路径，然后检查这个绝对路径是否以允许的基目录开头。比如基目录是/var/www/uploads/，规范化后如果变成/etc/passwd，直接拒绝。这比黑名单过滤../可靠得多，因为编码变体太多，黑名单永远列不全。

另一个思路是根本不让用户碰路径。文件用ID标识，服务端根据ID查数据库得到真实路径。用户传id=123，服务端查表发现对应/var/www/uploads/abc.jpg，然后读取。这样攻击者连../都插不进去。很多云存储API就是这么干的，虽然多了一次查询，但安全边界清晰。

权限控制也能兜底。Web进程别用root跑，读不了/etc/shadow，就算遍历成功也拿不到敏感内容。容器化部署时，把文件系统挂载成只读，或者用chroot限制根目录，都能大幅缩小影响面。我见过一个团队，所有上传文件放在独立分区，挂载时加上noexec,nosuid，就算被遍历到，也执行不了任何东西。

日志和监控别忽视。正常用户不会请求../../../../etc/passwd这种路径。WAF里加条规则，匹配到连续../就告警，往往能在扫描阶段就拦住。某次应急响应中，我们就是靠Nginx日志里大量%2e%2e%2f请求，定位到了攻击者IP，顺藤摸瓜发现他还在试探其他接口。

说到底，目录遍历是典型的设计缺陷，不是技术难题。开发时多写一行路径校验，比事后打补丁便宜得多。安全圈有句话：你永远不知道用户会输入什么，但你可以决定自己接受什么。把这句话刻在文件读取的代码旁边，比任何安全培训都管用。