一个网站如果直接把用户输入当成文件路径去读取，任意那它离出事就不远了。文件任意文件读取漏洞，漏洞说白了就是原理这么回事：程序本该只让用户访问特定文件，结果没做好校验，任意用户输入个 ../../etc/passwd 之类的文件路径，服务器就老老实实把系统文件内容吐出来了。漏洞

我见过最典型的原理一个案例，是任意某下载功能。URL 长这样：download?文件file=report.pdf。看着挺正常。漏洞有人把 report.pdf 换成 ../../../etc/passwd，原理页面直接返回了 root 用户信息。任意开发当时觉得“用户怎么会知道服务器路径”，文件但攻击者根本不需要知道——../ 这种相对路径符号，漏洞就是用来往上跳目录的。跳几次，总能摸到敏感位置。

路径穿越是怎么发生的

核心问题出在字符串拼接上。代码里写 basePath + userInput，然后交给文件读取函数。如果 userInput 里带 ../，拼接后的路径就跑到 basePath 外面去了。操作系统才不管你的意图，它只认最终路径。

还有一种情况是绝对路径注入。用户直接输入 /etc/shadow，程序没做前缀限制，照样读。某些语言的文件 API 还允许 URL 编码绕过，比如 %2e%2e%2f 解码后就是 ../。过滤器只查明文 ../ 的话，这招就溜过去了。

不只是 Web 入口

文件读取漏洞不限于 HTTP 参数。日志查看器、模板加载、配置文件导入、甚至图片处理库的 EXIF 解析，都可能中招。我印象很深的是一个 Java 应用，上传功能会把文件名拼到临时目录后读取。文件名里塞 ../../../../../../etc/hostname，上传接口没拦，读取接口也没拦，结果服务器主机名直接回显在响应里。攻击者靠这个确认了目标环境，后续利用就顺理成章了。

Windows 上也有类似玩法。..\..\..\windows\win.ini 是经典 payload。如果程序用反斜杠做路径分隔，过滤时只考虑正斜杠，那一样能穿。

为什么这类漏洞老是被忽略

开发者的注意力往往在 SQL 注入、XSS 这些“出名”的漏洞上。文件读取听起来人畜无害——不就是读个文件吗？但读到的可能是数据库配置、SSH 私钥、云服务凭证。拿到这些，攻击面瞬间扩大十倍。

另一个原因是框架背锅心理。用了 Spring、Django 就觉得自带防护。实际上框架只提供工具，路径校验还得自己写。比如 Python 的 os.path.join，如果第二个参数是绝对路径，它会直接丢弃第一个参数。很多人不知道这个行为，以为 join 一定安全。

临时补一句防御思路

别用黑名单过滤 ../。编码变体太多，绕不过来的。正确做法是白名单——只允许特定文件名，或者用 realpath 解析后检查是否还在预期目录内。Java 的 getCanonicalPath()、Python 的 os.path.realpath() 都是干这个的。解析完再判断前缀，比正则匹配靠谱得多。

还有，文件读取接口别用用户输入直接拼路径。用 ID 映射真实路径，数据库查一下，多写两行代码，省掉一堆麻烦。

这漏洞原理不复杂，但实战里出现频率高得离谱。说白了就是信任了不该信任的输入。写代码时多问一句“用户能不能控制这个值”，很多坑就能提前避开。