一个txt文件，系统里面存着密码，文件路径是漏洞/home/user/secret.txt。攻击者往URL里塞了../../../../etc/passwd，系统服务器居然乖乖把文件内容吐了出来。文件这不是漏洞什么高深攻击，就是系统系统文件读取漏洞最原始的形态——路径穿越。

问题出在开发者没过滤用户输入。文件你传什么路径，漏洞程序就拼什么路径去读文件。系统像../这种往上跳的文件符号，本应该在入口处就被拦下来，漏洞但很多代码就这么赤裸裸地暴露着。系统我见过某政府网站的文件后台，用?漏洞file=参数加载本地模板，结果把/etc/shadow的哈希值都拉出来了。那哥们儿当时就愣了，说这系统上线三年没人发现过。

这类漏洞最烦人的地方在于，它不挑语言。PHP有include，Java有FileInputStream，Python有open()——只要开发者图省事，把用户可控参数直接拼进文件路径，漏洞就诞生了。别以为用白名单就安全，有人试过用....//绕过过滤，因为某些正则只匹配../，没考虑重复斜杠和编码绕过。还有用URL编码%2e%2e%2f的，服务器解码后照样能穿越。

真正可怕的不是读文件本身，而是连锁反应。读到config.php，数据库账号密码到手；读到.git目录下的配置文件，整个项目源码泄露；读到/proc/self/environ，可能拿到内网IP和临时token。有个案例是攻击者读了/proc/self/fd/下的文件描述符，直接找到了正在运行的临时上传文件，把webshell写了进去。

修复方案其实不复杂。第一，绝对不要用用户输入直接拼接文件路径，要用basename()之类的函数提取文件名，再配合固定目录。第二，如果非得支持路径参数，那就做一个映射表，让用户传ID，你后台对应真实路径。第三，WAF规则里加一条：\.\./和\.\.\直接拒绝，别管编码不编码。

但现实是，很多系统就这么裸奔着。上次渗透测试，我拿一个?page=参数试了试../../../../etc/passwd，结果页面真的显示了root:x:0:0:root:/root:/bin/bash。当时我第一反应不是兴奋，是无奈——这种漏洞在OWASP Top 10里待了十几年，怎么还有人在犯？后来我看了看那套代码，注释里写着一句“此文件仅供内部使用”，下面就是file_get_contents($_GET['page'])。没法说，真的没法说。

防住这个漏洞，说穿了就一句话：别信任任何输入，文件路径尤其如此。把用户当傻瓜，把参数当毒药，你才能睡得着觉。至于那些已经上线的老系统，赶紧去翻翻日志里有没有../的记录，也许早就有人试过了，只是你没发现而已。