任意文件读取漏洞修复

去年冬天，任意一个做电商的文件朋友半夜给我打电话，说服务器上所有商品图片全变成了乱码。漏洞我远程连上去一看，修复日志里全是任意 GET /api/export?file=../../../../etc/passwd 这样的请求。攻击者没做别的文件，就是漏洞拿一个参数反复试路径。那个接口原本是修复给运营导出报表用的，参数直接拼进 file_get_contents()，任意连过滤都没做。文件数据没丢，漏洞但服务器上所有能读的修复文件——数据库配置、SSH密钥、任意甚至 /root/.bash_history——全被翻了一遍。文件

任意文件读取漏洞的漏洞修复，核心就一句话：别让用户输入的路径直接碰文件系统。但具体怎么做，得看场景。有人上来就写正则匹配 ../，结果攻击者用 ....// 或 URL 编码 %2e%2e%2f 就绕过去了。这种黑名单思路从根上就是错的。

我见过最离谱的修复方案，是在代码里加了个 str_replace('../', '', $path)。攻击者传 ..././，替换一次后变成 ../，照样穿越。正确的做法是白名单——只允许访问特定目录下的文件。比如导出报表，就限定在 /var/www/exports/ 里，用 realpath() 解析出绝对路径，然后检查这个路径是否以允许的目录开头。PHP 里这样写：

$base = '/var/www/exports/'; $real = realpath($base . $userInput); if ($real === false || strpos($real, $base) !== 0) {  die('Invalid path'); } 

注意 realpath() 会解析掉所有 .. 和符号链接，比手动替换可靠得多。但有个坑：如果文件不存在，realpath() 返回 false，你得区分“路径非法”和“文件不存在”，否则正常用户也会被拦截。

Java 里类似，用 Path.normalize() 然后 startsWith() 判断。Python 的 os.path.realpath() 同理。关键点是：先规范化，再比较前缀。别用字符串包含判断，/var/www/exports/../../etc 规范化后是 /etc，前缀比较直接失败。

有些场景没法用白名单。比如一个文件下载功能，用户要下载自己上传的任意文件，路径存在数据库里。这时候得用间接引用——数据库存文件ID，而不是路径。用户传 id=123，服务端查表拿到真实路径。这样攻击者连路径都控制不了。我见过一个 CMS，文件下载接口是 download.php?file=xxx，修复时改成 download.php?id=xxx，数据库里加个 files 表，立马干净了。

还有一类容易忽略的：压缩包解压。用户上传 zip，服务端解压时如果没检查条目名，攻击者可以构造一个包含 ../../../../etc/cron.d/evil 的压缩包，解压时直接写系统文件。修复方法是解压前遍历每个条目，用 realpath() 检查目标路径是否在允许目录内。Python 的 zipfile 模块有个 extractall() 默认不检查，得手动处理。

日志和监控也得跟上。我在那个电商服务器上后来加了条规则：任何包含 .. 或 %2e%2e 的请求直接返回 400 并记录 IP。不是用来拦截——白名单已经拦住了——而是用来发现谁在扫描。三天内封了十几个 IP，全是自动化工具在批量试。

最后说个真实教训。有个团队用 Nginx 的 alias 配置静态资源，写成了 location /static { alias /var/www/static/; }，结果访问 /static../etc/passwd 能读到系统文件。Nginx 的 alias 和 root 对路径的处理不一样，alias 会直接拼接。修复方法是在 location 里加 if ($request_uri ~ "\.\.") { return 403; }，或者干脆用 root 替代 alias。这种配置层面的漏洞，代码里再安全也没用。

修复任意文件读取，本质是把用户输入从路径拼接中彻底剥离。能不用路径就不用，必须用时白名单加规范化。别相信任何黑名单，别自己写过滤函数。就这些。