去年秋天，径漏洞一个做安全审计的径漏洞朋友给我看了份漏洞报告。某电商平台的径漏洞商品图片接口长这样：/api/image?file=product/123.jpg。他把参数改成 ../../../etc/passwd，径漏洞服务器直接把系统用户列表吐了出来。径漏洞就这么简单。径漏洞没有花哨的径漏洞注入语句，没有绕WAF的径漏洞编码技巧，一个点斜杠就捅穿了整条防线。径漏洞

这就是径漏洞路径穿越漏洞。本质上是径漏洞程序太信任用户的输入，把拼接后的径漏洞文件路径直接丢给文件系统去读。攻击者用 ../ 跳出预期目录，径漏洞就能摸到本该锁死的径漏洞文件。听起来像上古时代的径漏洞漏洞？对，它确实老，OWASP Top 10 里都算常客了，但每年仍有大量新系统栽在上面。

我翻过不少CVE记录，印象最深的是某款企业级VPN网关的固件更新功能。接口接收一个 filename 参数，服务端用 /firmware/ 加上用户传的值来定位文件。攻击者传 ../../../var/run/secrets/kubernetes.io/serviceaccount/token，在K8s环境里直接拿到集群的认证令牌。从路径穿越到接管整个容器编排平台，链条就这么串起来了。这种案例说明一个问题：路径穿越很少单独存在，它更像一把钥匙，能打开后面一连串的门。

为什么这种漏洞屡禁不止？我观察到一个现象——很多开发者压根不知道 ../ 在文件系统里意味着什么。写业务逻辑时把路径当普通字符串处理，拼接完就调用 readFile 或者 open。更麻烦的是，不同操作系统的路径分隔符还不一样，Windows 用反斜杠，Linux 用正斜杠，URL编码又能把 %2e%2e%2f 变回 ../。绕过手法五花八门，过滤黑名单几乎防不住。

有人会说，那我用白名单不就行了？限定只能读 public/ 目录下的文件。思路对，但实现很容易出岔子。比如先检查路径里有没有 ..，没有就放行，结果攻击者用 ....// 绕过——过滤掉中间的 ../ 后，剩下的字符又拼成了 ../。这种递归替换的坑，我至少在三个开源项目里见过。

真正靠谱的做法其实不复杂。把用户输入的文件名做规范化处理，用 realpath 拿到绝对路径，然后判断这个路径是否以预期的基目录开头。Node.js 里用 path.resolve 加 path.relative 组合检查，Java 用 Path.normalize() 再比对。关键点在于：先规范化，再校验，别反过来。

还有个容易被忽略的场景——文件上传。用户传个 ../../../../var/www/html/shell.php 当文件名，服务端如果不做处理直接保存，就等于给攻击者写文件的权利。我见过一个 CMS 系统，上传接口只检查了扩展名是不是 .jpg，文件名原样保留。攻击者传 ../../config.php，覆盖掉数据库配置文件，站点直接瘫痪。

说回我朋友那份报告。他最后在建议栏里写了句话：“不要用字符串拼接来构造文件路径，这是二十年前就该淘汰的做法。”话有点冲，但没毛病。路径穿越漏洞的修复成本极低，几行校验代码的事，可一旦被利用，泄露的可能是密钥、源码、用户数据，甚至整个服务器的控制权。这笔账怎么算都不划算。

下次写文件操作相关代码时，多花三十秒想想：这个路径参数，用户能不能塞点奇怪的东西进来？如果答案是“能”，那就老老实实做规范化校验。别等漏洞报告送到面前才后悔。