Web安全实战：路径遍历漏洞原理、复现与防御指南

1. 项目概述：一次典型的Web应用路径遍历漏洞复现

最近在安全圈里，CVE-2025-54100这个编号开始被频繁提及。这是一个典型的Web应用路径遍历漏洞，影响了一款在特定场景下广泛使用的文件管理中间件。简单来说，攻击者可以利用这个漏洞，绕过应用设定的访问限制，读取或下载服务器上本不应被访问的敏感文件，比如配置文件、日志、甚至是源代码。这类漏洞虽然原理不复杂，但危害极大，一旦被利用，可能导致服务器敏感信息泄露，甚至为后续攻击打开大门。

我之所以花时间深入研究并复现这个CVE，是因为路径遍历（Path Traversal）是Web安全中经久不衰的“经典”问题。尽管开发框架和安全规范日益完善，但在参数处理、路径拼接等细节上稍有不慎，就可能埋下隐患。通过亲手复现，不仅能深刻理解漏洞的成因和利用条件，更能掌握在代码审计和渗透测试中快速识别此类问题的“嗅觉”。无论你是安全研究员、渗透测试工程师，还是希望提升代码安全性的开发者，跟着我走一遍这个复现过程，都会大有裨益。整个过程我们会在一个完全可控的本地实验环境（使用Docker搭建漏洞靶场）中进行，确保安全、合法。

2. 漏洞原理深度解析：路径拼接的“信任危机”

2.1 核心漏洞成因：不当的路径规范化与校验缺失

CVE-2025-54100的核心问题，出在Web应用对用户可控的输入参数进行文件路径拼接时，没有进行充分的安全校验和规范化处理。我们假设受影响的应用有一个文件下载或预览功能，其接口大致逻辑如下：

1. 前端请求一个文件，例如：GET /download?file=report.pdf
2. 后端接收到file参数后，会将其与一个预设的基础目录进行拼接。
3. 拼接后的完整路径可能是：/var/www/uploads/+report.pdf=/var/www/uploads/report.pdf
4. 应用然后使用这个拼接路径去读取文件内容并返回给用户。

漏洞就隐藏在第二步。如果应用没有对用户传入的file参数进行严格的过滤，攻击者可以传入包含目录遍历序列（如../）的恶意参数。例如，攻击者构造请求：GET /download?file=../../../etc/passwd。后端如果直接拼接，路径就变成了：/var/www/uploads/../../../etc/passwd。在操作系统进行路径解析时，../表示上级目录，经过解析，最终访问的路径就变成了/etc/passwd，从而成功越权读取了系统的密码文件。

注意：这里/etc/passwd只是一个经典示例，实际中可能读取数据库配置文件（如config.php、.env）、日志文件、备份文件等，危害极大。

2.2 关键利用条件与绕过技巧

并非所有存在路径拼接的地方都能被利用。成功利用CVE-2025-54100这类漏洞，通常需要满足几个条件，了解这些条件也是我们审计和防御的关键：

1. 用户输入直接参与路径拼接：这是前提。文件名、路径名等参数必须来自用户请求且未被充分过滤。
2. 应用具有读取文件的权限：Web服务进程（如www-data, nginx用户）必须有权限读取目标敏感文件。
3. 路径解析发生在操作系统层面：最终用于访问文件的系统调用（如open()、readfile()）接收的是拼接后的字符串，并由操作系统内核进行解析。如果应用在自身逻辑层面对../进行了拦截，但拦截逻辑有缺陷（如只过滤一次），就可能被绕过。

常见的绕过技巧包括：

• 编码绕过：使用URL编码（%2e%2e%2f表示../）、双重编码（%252e%252e%252f）或Unicode编码，以绕过基于字符串匹配的简单过滤。

• **绝对路径覆盖**：如果拼接逻辑是简单的字符串连接，且基础目录处理不当，攻击者可能直接传入绝对路径（如`/etc/passwd`）来覆盖整个基础路径。

• 空字节截断：在一些老旧或特定语言的处理中，在路径后添加空字节（%00）可能截断后续的校验或追加的后缀。例如file=../../../etc/passwd%00.jpg，如果后端代码是base_path + user_input + “.jpg”，空字节可能导致系统只读取/etc/passwd。

理解这些原理后，我们就能有的放矢地进行复现了。接下来，我们将搭建一个模拟环境，亲手触发这个漏洞。

3. 实验环境搭建与漏洞复现实操

为了安全、可重复地复现漏洞，我们不会去找真实的受影响系统，而是使用一个专门用于安全学习的漏洞靶场环境。这里我选择用Docker快速部署一个包含类似漏洞场景的靶场。

3.1 环境准备与靶场部署

首先，确保你的实验机器上安装了Docker和Docker Compose。我们使用一个广受好评的Web安全学习平台——DVWA（Damn Vulnerable Web Application）的Docker版本，但它本身可能没有我们要的精确漏洞。因此，我更倾向于使用一个专门训练路径遍历的靶场，比如“Web Security Academy”的实验室环境，或者自己构建一个简单的漏洞Demo。

这里，我演示如何快速构建一个最简单的漏洞Demo容器：

1. 创建漏洞应用文件：新建一个目录，例如cve-2025-demo。

   mkdir cve-2025-demo && cd cve-2025-demo

2. 编写有漏洞的PHP脚本：创建index.php。

   <?php // 模拟存在CVE-2025-54100漏洞的代码 $base_dir = '/var/www/html/uploads/'; // 预设的基础目录 if (isset($_GET['file'])) { $file = $_GET['file']; // 直接获取用户输入，未过滤！ $path = $base_dir . $file; // 危险的路径拼接 // 模拟读取文件内容（真实漏洞可能直接输出文件） // 这里为了演示安全，只显示路径，不真正读取 echo "尝试访问的路径（模拟）： " . htmlspecialchars($path) . "<br>"; echo "解析后的真实路径（模拟）： " . htmlspecialchars(realpath($path)); } else { echo "请使用 ?file=filename 参数请求文件。"; } ?>

   实操心得：在真实复现中，我们可能需要一个真正会读取并返回文件内容的脚本。但为了绝对安全且聚焦于漏洞原理，我们先使用这个“无害”的版本进行路径构造演示。后续可以替换为一个在严格隔离环境下真正有风险的脚本。

3. 编写Dockerfile：创建Dockerfile。

   FROM php:8.2-apache RUN docker-php-ext-install mysqli && docker-php-ext-enable mysqli COPY index.php /var/www/html/ RUN mkdir -p /var/www/html/uploads && \ echo "This is a safe upload file." > /var/www/html/uploads/safe.txt && \ echo "Sensitive system file content (simulated)" > /etc/passwd_simulated # 注意：我们复制了一个模拟的passwd文件，避免触及真实系统文件

4. 构建并运行容器：

   docker build -t cve-2025-demo . docker run -d -p 8080:80 --name cve-2025-lab cve-2025-demo

现在，访问http://localhost:8080/就能看到我们的漏洞演示页面了。

3.2 漏洞验证与利用步骤

环境就绪后，我们开始验证和利用漏洞。

1. 正常功能测试：首先，测试正常功能。访问http://localhost:8080/?file=safe.txt。页面会显示拼接后的路径，例如尝试访问的路径（模拟）： /var/www/html/uploads/safe.txt。这说明文件参数正常工作。

2. 基础路径遍历测试：现在，尝试利用漏洞。访问http://localhost:8080/?file=../../../etc/passwd_simulated。

   • 观察结果：页面显示的拼接路径会是/var/www/html/uploads/../../../etc/passwd_simulated，而realpath函数解析后，可能会显示/etc/passwd_simulated（取决于容器内的路径存在性）。这证明我们构造的路径成功穿越了目录，指向了系统文件。
   • 关键点：这里我们使用的是realpath函数来模拟操作系统解析后的结果。在真实漏洞中，如果后端代码直接使用拼接路径去readfile()或file_get_contents()，那么/etc/passwd（或模拟文件）的内容就会被输出到响应中。

3. 编码绕过测试：假设原始代码有一个简单的过滤：str_replace('../', '', $file)。我们可以尝试编码绕过。访问http://localhost:8080/?file=..%2f..%2f..%2fetc%2fpasswd_simulated（%2f是/的URL编码）。如果过滤逻辑没有解码后再过滤，这个请求可能绕过检查。

4. 利用工具进行自动化探测：在实际渗透测试中，我们不会手动构造每一个Payload。可以使用 Burp Suite 的 Intruder 模块，或者命令行工具如ffuf，加载包含常见路径遍历Payload的字典进行模糊测试。

   # 使用ffuf进行模糊测试示例（需安装ffuf） ffuf -u "http://localhost:8080/?file=FUZZ" -w /path/to/traversal-payloads.txt -fs 0

   注意事项：在测试真实目标前，务必获得书面授权。未经授权的测试是违法行为。

3.3 漏洞复现的深入：从信息显示到内容读取

我们之前的Demo只显示了路径。要完整复现“文件内容读取”的影响，我们需要稍微修改一下漏洞脚本，但必须在高度可控的环境下进行。以下操作仅在隔离的Docker实验容器中进行。

1. 修改index.php为有风险的版本（仅用于教育目的）：

   <?php $base_dir = '/var/www/html/uploads/'; if (isset($_GET['file'])) { $file = $_GET['file']; $path = $base_dir . $file; // 危险操作：直接读取文件并输出 if (file_exists($path)) { header('Content-Type: text/plain'); readfile($path); } else { echo "File not found: " . htmlspecialchars($path); } } ?>

2. 重建并运行容器（使用新的镜像名）：

   docker build -t cve-2025-demo-risky . docker run -d -p 8081:80 --name cve-2025-risky-lab cve-2025-demo-risky

3. 此时，访问http://localhost:8081/?file=../../../etc/passwd_simulated，你将直接看到模拟的敏感文件内容被输出到浏览器。这就完整再现了CVE-2025-54100漏洞被成功利用后的效果。

4. 代码审计视角：如何发现此类漏洞

复现漏洞之后，我们更应该掌握如何主动发现它。从开发和安全审计的角度，有以下关键检查点：

4.1 危险函数与代码模式识别

在不同的编程语言中，需要警惕的文件操作函数和模式：

审计时，在代码中全局搜索这些函数名，并追踪其参数来源，是快速定位潜在漏洞的有效方法。

4.2 安全的路径校验实现方案

发现危险代码后，如何修复？核心原则是：白名单优于黑名单，规范化后校验。

方案一：白名单机制（最推荐）如果业务上只允许访问有限的文件，建立白名单是最安全的。

$allowed_files = ['report.pdf', 'contract.docx', 'data.csv']; if (in_array($_GET['file'], $allowed_files)) { $path = $base_dir . $_GET['file']; // 安全地读取文件 } else { die('Access denied.'); }

方案二：规范化后前缀校验（通用方案）当文件范围不固定时，使用此方案。

$user_input = $_GET['file']; $base_dir = '/var/www/html/uploads/'; // 1. 规范化路径 $full_path = realpath($base_dir . $user_input); // 2. 检查规范化后的路径是否以基准路径开头 if ($full_path === false || strpos($full_path, realpath($base_dir)) !== 0) { die('Invalid file path.'); } // 3. 安全检查通过，读取文件 readfile($full_path);

重要提示：realpath()函数会解析..和符号链接，并返回绝对路径。校验strpos($full_path, realpath($base_dir)) === 0确保最终路径没有“逃出”安全目录。注意realpath在文件不存在时返回false，需要处理。

5. 防御加固与安全开发实践

理解了漏洞和审计方法，最终目标是构建更安全的系统。以下是从开发到部署的全链路防御建议。

5.1 开发阶段的安全编码规范

1. 最小化用户输入信任：永远不要相信客户端传来的任何路径信息。视其为污染数据。
2. 使用安全的API：尽可能使用框架提供的安全文件操作方法。例如，在Spring框架中使用Resource接口；在Flask中使用send_from_directory。
3. 实施严格的输入验证：结合白名单（首选）和规范化校验。对于文件名，可以校验其是否符合预期的字符集（如字母、数字、连字符、下划线）和长度。
4. 运行在最小权限下：运行Web服务的操作系统用户（如www-data、nginx）应仅拥有对Web根目录及其子目录的必要读写权限，绝不能以root身份运行。
5. 代码审查与自动化扫描：将路径遍历漏洞检查项纳入代码审查清单。使用SAST（静态应用安全测试）工具，如SonarQube、Checkmarx，在CI/CD流水线中自动扫描代码。

5.2 运维与部署层面的缓解措施

即使应用代码存在隐患，运维层面也能设置防线：

1. 容器化与文件系统隔离：使用Docker/Kubernetes等容器技术，将应用运行在隔离的环境中。通过只读挂载（read-only）或绑定挂载（bind mount）严格控制容器内进程可访问的主机目录。
2. Web服务器配置：在Nginx或Apache配置中，可以设置规则阻止请求中包含..的URL。
   • Nginx示例：

     location /download { if ($request_uri ~* "\.\.") { return 403; } # ... 其他代理配置 }

   • 注意：这只是一道辅助防线，不能替代应用层校验，因为攻击者可能使用编码绕过。
3. 文件系统权限加固：确保Web根目录以外的敏感目录（如/etc,/home,/root）对Web服务进程用户不可读。
4. 部署WAF（Web应用防火墙）：配置成熟的WAF（如ModSecurity）规则集，可以有效地拦截常见的路径遍历攻击Payload，为存在漏洞的应用提供临时保护。

5.3 漏洞修复后的验证流程

修复漏洞后，必须进行验证：

1. 回归测试：确保原有的正常文件下载功能不受影响。
2. 渗透复测：使用之前成功的Payload（如../../../etc/passwd）及其各种编码变形进行测试，确认均返回“拒绝访问”或“文件不存在”等错误，而非文件内容。
3. 自动化扫描：再次使用动态应用安全测试（DAST）工具或手动渗透测试工具对修复后的接口进行扫描。

路径遍历漏洞就像一扇忘记上锁的后门，攻击者一旦发现便可长驱直入。通过这次对CVE-2025-54100的深入复现与分析，我们可以看到，安全无小事，往往就败在细节处理上。作为开发者，在编写每一行处理用户输入的代码时，都要心怀警惕；作为安全人员，则需要练就一双能快速识别这些危险模式的“火眼金睛”。防御的核心，始终在于不信任任何外部输入，并在最终执行操作前，进行彻底的、基于规范化路径的校验。把这个案例的思路和方法带入你的日常工作和学习，下次再看到文件下载、预览、模板包含这类功能时，你就能本能地去思考：这里的路径，真的安全吗？