文件包含漏洞产生的条件不包括

上周帮同事看一段 PHP 代码，他信誓旦旦说“这地方肯定有文件包含漏洞”，包含包括结果我扫了一眼，漏洞参数传进去直接拼接到了 include 后面，产生但前面做了 basename() 处理，文件还硬编码了目录前缀。包含包括他挠头问我：“那到底啥时候才算文件包含漏洞？漏洞条件到底是啥？”我回了一句：“你先搞清楚哪些不是条件，比背定义管用。产生”

文件包含漏洞的文件根子在于“用户能左右被包含的文件路径”，但这句话太笼统。包含包括很多人以为只要代码里写了 include $_GET['page']; 就必然中招，漏洞其实不然。产生动态包含本身只是文件语法特性，真正产生漏洞需要一串条件同时成立。包含包括反过来，漏洞有些东西看起来像条件，实际上跟漏洞成因没半毛钱关系。

不包括“服务器必须开启 allow_url_include”。这个选项常被当成远程文件包含（RFI）的开关，但本地文件包含（LFI）根本不依赖它。哪怕 allow_url_include=Off，攻击者照样能用 ../../etc/passwd 或者 php://filter 读源码。我见过一个 CTF 题，环境里这个选项关得死死的，选手用伪协议照样拿 flag。所以它顶多算 RFI 的助推器，不是文件包含漏洞的必要条件。

不包括“包含的文件必须是可执行脚本”。有人觉得只有包含 .php 文件才会触发漏洞，这误解挺深。包含一个 .txt 日志文件，如果里面写入了 PHP 代码，照样能解析执行——前提是文件后缀没被服务器特殊处理。更常见的是包含图片马，include 'uploads/evil.jpg';，只要 jpg 里藏了 <?php system($_GET['c']); ?>，PHP 解释器可不管后缀，直接当代码跑。所以“文件类型限制”根本不是漏洞成立的条件，反而经常是绕过手段。

我自己的经验：审计代码时看到 include、require、include_once 这些函数，第一反应不是“有漏洞”，而是“参数能不能控、有没有过滤、包含路径是否固定”。三个里缺一个，漏洞就不成立。

不包括“必须使用动态变量作为包含路径”。静态写死的包含永远安全，比如 include 'header.php';。但动态不代表一定漏洞——如果动态值来自硬编码数组的键，比如 $pages = ['home'=>'home.php', 'about'=>'about.php']; include $pages[$_GET['p']] ?? 'home.php';，攻击者传 ?p=../../etc/passwd 只会得到 home.php，因为数组里没有那个键。这种白名单映射反而堵死了漏洞。所以“动态”是必要不充分条件，不能算作漏洞产生的独立条件。

不包括“服务器操作系统必须是 Linux”。Windows 下照样有文件包含，只是路径分隔符和敏感文件不同。Linux 读 /etc/passwd，Windows 读 C:\Windows\win.ini，或者用 php://filter 通杀。我测试过 IIS+PHP 的环境，include $_GET['f']; 传 ..\..\windows\system32\drivers\etc\hosts 一样能读。系统类型影响的是利用方式，不是漏洞成因。

那到底什么才是条件？简单说：用户输入能到达包含函数的路径参数，且没有做有效的白名单或路径规范化，同时服务器配置允许被包含的文件被解析或读取。这三个缺一不可。至于 allow_url_include、文件后缀、操作系统、是否动态变量——这些都是干扰项，或者只影响利用难度，不影响漏洞是否存在。

下次再有人问你“文件包含漏洞产生的条件不包括什么”，你可以直接告诉他：别把利用技巧当成因。条件只有那三条，剩下的都是烟雾弹。搞安全的人容易犯一个毛病——把“能利用”和“有漏洞”混为一谈。能利用是结果，有漏洞是原因。原因没找对，修修补补都是白费劲。