上周排查一个客户的目录内网服务器，发现Web根目录下有个叫“backup”的遍历文件夹，里面整整齐齐躺着三份数据库配置文件。漏洞问运维怎么回事，可通他说是过修改配几个月前临时放进去的，忘了删。解决访问路径是目录/backup/db_config.php——不需要任何漏洞利用工具，浏览器地址栏敲进去就能下载。遍历这就是漏洞目录遍历漏洞最朴素的样子：本该藏起来的东西，被一条直白的可通路径暴露了。

目录遍历（Directory Traversal），过修改配也有人叫路径穿越，解决核心问题出在服务器对用户输入的目录路径没有做严格过滤。攻击者用../这类相对路径符号，遍历就能跳出Web根目录的漏洞限制，去读系统里的任意文件。比如/download?file=../../../etc/passwd，如果后端代码直接拿这个参数去拼文件路径，Linux系统的用户账户信息就裸奔了。

但今天想聊的不是怎么防这个漏洞——网上教程一抓一大把。我想说的是一个容易被忽略的修复思路：改配件。

先解释一下“配件”在这里指什么。一个Web应用的运行依赖很多组件：Web服务器（Nginx、Apache）、应用服务器（Tomcat、IIS）、后端语言运行时（PHP、Java、Node.js）、框架（Spring、Django、Express）。这些组件各自都有路径处理逻辑。很多时候，漏洞不在你写的业务代码里，而在某个组件的默认配置上。

举个例子。Nginx有个alias指令，用来把某个URL路径映射到文件系统的另一个位置。配置不当就会出问题。比如：

location /static {  alias /var/www/app/static/; }

看起来没问题。但如果请求是/static../，Nginx在某些版本里会把../拼接到alias路径后面，变成/var/www/app/static/../，也就是/var/www/app/。攻击者就能读到应用目录下的任何文件。这个问题的修复方式不是去改业务代码，而是调整Nginx配置——要么升级到修复了该问题的版本，要么改用root指令替代alias，要么在location块里加if判断拦截..。

再比如Tomcat。老版本Tomcat对URL编码的%2e%2e%2f处理有缺陷，攻击者可以用编码后的路径穿越读取WEB-INF下的敏感文件。修复方案里有一条：在server.xml的Connector节点上设置allowBackslash="false"，或者升级Tomcat版本。这同样是改配件，不是改你写的Servlet。

我见过一个真实案例。某企业的文件下载接口做了白名单校验，只允许下载/data/reports/下的文件。代码层面看起来无懈可击。但他们用的PHP版本是5.3，那个版本有个已知问题：file_get_contents()在处理某些路径时，..的解析和校验逻辑不一致。攻击者构造了一个带空字节的路径/data/reports/../../etc/shadow%00.pdf，绕过了白名单检查。后来他们把PHP升级到5.6，问题直接消失。业务代码一行没动。

这个思路的价值在于：当你在代码层面已经做了能做的防护，仍然被绕过时，往上走一层，看看是不是某个组件的默认行为在拖后腿。Web服务器、运行时、框架，它们对路径的解析规则各不相同，版本之间的差异也很大。一个在PHP 7.4上被正确拦截的路径，在PHP 5.3上可能就穿过去了。

当然，这不是说代码层面的过滤不重要。输入验证、路径规范化、白名单校验，这些该做还得做。但“改配件”提供了一个额外视角：漏洞的根源可能不在你的代码里，而在你依赖的基础设施里。修复它，有时候只需要改一行配置，或者升一个版本号。

那个客户后来把backup文件夹删了，Nginx也升了级。我问他之前知不知道alias那个坑，他说不知道，以为只要代码写对了就没事。这大概是很多开发者的盲区——盯着自己的一亩三分地，忘了脚下的地基也是别人写的。