一个午后，文件某甲方运维把一份日志文件甩到我面前——里面密密麻麻全是漏洞同一个IP的请求，每一条都在问同一个参数：?文件file=。那是漏洞个下载功能，用户传文件名，文件服务端拼路径，漏洞读文件，文件返回内容。漏洞

问题出在没过滤../。文件攻击者传?漏洞file=../../../../etc/passwd，服务端就老老实实把系统账号文件吐了出来。文件测试环境，漏洞没设权限，文件也没做白名单。漏洞就这么简单，文件一个能读服务器上任意文件的洞，横在那里。

文件读取漏洞的核心，就是“用户输入被当成了文件路径的一部分”。这不是什么高深技巧，更像服务端把本该自己决定的路径选择权，轻易交给了陌生人。你问它“把门打开”，它不问你是谁，直接递钥匙。

这类漏洞常见于三类地方：下载附件、预览图片、导出报表。业务逻辑里总得有个文件名参数，开发者图省事，直接拼进路径。我见过最离谱的一个案例，是某后台的PDF导出功能，文件名参数直接拼进服务器本地路径，攻击者把参数改成/proc/self/environ，居然把PHP进程的环境变量读出来了——里面有数据库密码、密钥，全裸奔。

读文件只是第一步，真正可怕的是后续。能读/etc/passwd不算什么，能读/proc/self/cmdline就知道你跑什么框架，读/proc/self/environ拿密钥，读/etc/nginx/nginx.conf摸清目录结构。要是配合日志注入，连源码都能一点一点抠出来。这就好比你家门锁没坏，但钥匙孔里能看见整个屋子的装修图纸——问题不在锁，在于你允许别人趴门缝看。

修复方案其实不复杂，但总有人绕远路。最蠢的做法是过滤../字符串，攻击者换个编码就绕过，比如..%2f或者....//。稍微聪明点的用realpath()校验最终路径是否在允许目录内，这算及格。再严格点，干脆不接收文件名，用ID或哈希值去数据库里查对应文件——从根上断掉路径拼接这条路。我碰过一家金融公司，他们更绝，文件全部存OSS，应用层只存对象键，下载时由OSS签名URL，应用本身碰不到真实文件系统。

还有个细节容易被忽略：文件上传功能往往和读取漏洞相伴相生。攻击者先传一个带恶意内容的文件上去，再通过读取漏洞把它包含执行——这就从“读文件”升级成了“远程代码执行”。所以别以为只是泄露点信息，链条一旦打通，权限就没了。

你问怎么自查？别等扫描器报。拿你业务里所有带文件名参数的接口，逐个试。传../../../../etc/passwd，看返回包里有没有root:字样。有，就修。没有，再看参数是不是支持绝对路径。别嫌麻烦，这玩意儿比SQL注入更隐蔽，因为它不报错，只默默把文件内容吐给你——等你发现的时候，敏感信息早就躺在别人数据库里了。

最后说句实在话：文件读取漏洞不是技术门槛多高，而是开发者对“用户输入”四个字缺乏敬畏。你以为参数是file，攻击者看到的是一扇没上锁的后门。修起来不难，难的是每次写路径拼接时，多问自己一句——如果用户传的是/呢？