Tomcat RewriteValve目录遍历漏洞CVE-2025-55752原理分析与安全加固

1. 项目概述与漏洞背景

最近在梳理Apache Tomcat的历史安全公告时，一个编号为CVE-2025-55752的漏洞引起了我的注意。这是一个关于Tomcat内置的RewriteValve组件存在的目录遍历漏洞。对于任何在生产环境中部署了Tomcat，并且使用了URL重写功能来美化链接或进行请求转发的团队来说，这个漏洞都是一个需要严肃对待的安全隐患。它允许攻击者通过精心构造的请求，绕过预期的目录限制，访问到Web应用根目录之外的文件，比如系统配置文件、日志文件，甚至是源代码。这听起来可能有点抽象，我打个比方：这就像你家的防盗门（Web应用的安全边界）上有一个猫眼（RewriteValve），本来设计是让你看清门外是谁，但因为这个猫眼本身的缺陷，攻击者能用一根特制的“钩子”通过猫眼伸进来，从门内的玄关桌上勾走钥匙。虽然Tomcat本身是一个久经考验的容器，但这类“边界组件”的细微逻辑缺陷，往往就是安全防线上最容易被突破的薄弱点。

这个漏洞影响的范围其实不小。根据官方公告，它影响的是Apache Tomcat 11.0.0-M1到11.0.1、10.1.0-M1到10.1.26、9.0.0-M1到9.0.94以及8.5.0到8.5.100这些版本。如果你正在使用这些版本中的任何一个，并且配置中启用了RewriteValve，那么你的应用就暴露在风险之下。我之所以花时间深入研究并复现它，是因为在实战中，很多开发者和运维对RewriteValve的配置和潜在风险并不完全了解，往往是从网上复制一段配置就用上了，缺乏对安全边界的审视。通过这次复现，我希望不仅能清晰地展示漏洞的成因和利用方式，更能讲明白在Tomcat中处理用户可控路径时，有哪些常见的“坑”以及如何从根本上加固配置。

2. RewriteValve工作机制与漏洞原理深度解析

2.1 RewriteValve是什么？它通常怎么用？

在深入漏洞之前，我们得先搞清楚RewriteValve到底是干什么的。它不是Tomcat的默认必选组件，而是一个可选的价值（Valve）。价值可以理解为Tomcat处理请求流水线上的一个“处理器”或“过滤器”。RewriteValve的功能，顾名思义，就是对传入的HTTP请求URL进行重写。

它的典型应用场景有哪些呢？最常见的有两个。第一，URL美化（Pretty URLs）。比如你有一个动态页面，原始URL可能是https://example.com/product?id=123，看起来不太友好也不利于SEO。通过配置RewriteValve，你可以将它重写为https://example.com/product/123。第二，请求转发和路由。在有些架构中，你可能希望将所有对特定路径的请求，都转发给后端另一个应用或Servlet处理，这时也可以用RewriteValve来实现，而不是依赖前端Web服务器（如Nginx/Apache HTTPD）的重写规则。

它的配置通常放在Tomcat的conf/server.xml文件里，在对应的<Host>或<Context>标签内添加。一个最简单的配置示例如下：

<Valve className="org.apache.catalina.valves.rewrite.RewriteValve" />

然后，你需要在Web应用的WEB-INF目录下创建一个rewrite.config文件，里面用类似Apache mod_rewrite的语法来定义重写规则。例如，一条将/product/123重写到/product?id=123的规则可能长这样：

RewriteRule ^/product/([0-9]+)$ /product?id=$1

2.2 漏洞根源：路径规范化处理的逻辑缺陷

那么，CVE-2025-55752这个目录遍历漏洞到底出在哪里呢？核心问题出在RewriteValve对请求URI（requestURI）和重写目标路径的处理逻辑上，特别是在进行“路径规范化”（Path Normalization）时出现了偏差。

路径规范化是一个关键的安全步骤。它的目的是清理用户输入的路径中的一些特殊序列，比如.（当前目录）、..（上级目录）以及多余的斜杠/，将其转换为一个标准、绝对且安全的路径。例如，/app/../WEB-INF/web.xml经过规范化后应该变成/WEB-INF/web.xml。Tomcat的核心请求处理逻辑（org.apache.catalina.core.ApplicationContext的getResource()和getResourceAsStream()方法）在最终获取资源前，会严格执行这个规范化过程，这是防止目录遍历的第一道防线。

然而，RewriteValve在早期版本中存在一个逻辑漏洞：它在应用重写规则时，可能使用了未经充分规范化的路径作为后续处理的输入。具体来说，攻击者可以构造一个包含..序列的请求URI，这个URI在进入RewriteValve时，由于某些规则匹配或处理流程，导致..序列没有被正确消除或校验，进而使得重写后的目标路径指向了Web应用根目录（docBase）之外的位置。

想象一下这个流程：

1. 攻击者发送请求：GET /static/../../../etc/passwd HTTP/1.1
2. 请求到达Tomcat，RewriteValve介入处理。
3. RewriteValve的规则引擎在处理这个URI时，可能因为某条规则（甚至是默认或错误的配置）匹配成功，决定不对其进行重写，或者重写成一个仍然包含..的路径。
4. 关键点：RewriteValve在将这个（可能仍不规范的）路径传递给Tomcat核心资源获取逻辑时，没有触发与核心逻辑同等严格的规范化检查，或者传递的上下文信息有误。
5. Tomcat核心根据这个“有问题”的路径去定位资源，..序列生效，成功跳出了Web应用目录，访问到了/etc/passwd系统文件。

注意：以上是一个概念性描述。实际利用链可能更复杂，涉及特定规则配置下RewriteValve内部resourcePath等变量的处理错误。官方修复的核心就是确保在RewriteValve内部，任何用于最终资源查找的路径，都必须经过与Tomcat核心完全一致且不可绕过的规范化过程。

2.3 受影响的版本与配置条件

理解漏洞原理后，我们就能更精确地定位风险点：

• 受影响版本：Apache Tomcat 11.0.0-M1 至 11.0.1， 10.1.0-M1 至 10.1.26， 9.0.0-M1 至 9.0.94， 8.5.0 至 8.5.100。只要你的Tomcat版本落在这个区间内，就存在潜在风险。
• 必要配置条件：必须在server.xml中启用了RewriteValve。如果你的配置里根本没有这个<Valve>标签，那么即使版本受影响，漏洞也无法被触发。
• 利用条件：攻击者需要能够向部署了受影响Tomcat且启用了RewriteValve的Web应用发送HTTP请求。这通常意味着应用是对外提供服务的。

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

纸上得来终觉浅，绝知此事要躬行。安全研究尤其如此，只有亲手搭建环境、触发漏洞，才能对它的危害性和利用条件有最直观的感受。下面我就带你一步步复现CVE-2025-55752。

3.1 环境准备：选择与部署受影响版本

首先，我们需要一个存在漏洞的Tomcat环境。为了安全且方便，强烈建议在虚拟机或隔离的Docker环境中进行。

方案一：使用Docker快速搭建（推荐）这是最干净、最便捷的方式。我们可以直接从Apache官方镜像仓库拉取一个受影响版本的Tomcat。

# 拉取一个受影响的Tomcat版本，例如 9.0.94 docker pull tomcat:9.0.94-jdk11-temurin # 运行容器，将webapps目录映射到本地以便修改配置，并暴露8080端口 docker run -d --name vulnerable-tomcat -p 8080:8080 -v $(pwd)/webapps:/usr/local/tomcat/webapps tomcat:9.0.94-jdk11-temurin

运行后，访问http://localhost:8080应该能看到Tomcat的默认主页。

方案二：手动下载安装如果你习惯手动部署，可以去Apache Tomcat官网的归档目录下载特定版本。例如，下载apache-tomcat-9.0.94.zip，解压后运行bin/startup.sh（Linux）或bin/startup.bat（Windows）。

3.2 配置RewriteValve与诱导规则

默认情况下，RewriteValve是没有启用的。我们需要手动配置它，并且为了演示漏洞，我们故意设置一条可能“放大”问题的规则。实际上，即使是一条看似无害的规则，在漏洞版本中也可能成为利用的跳板。

1. 编辑server.xml： 进入Tomcat的conf目录，找到server.xml文件。在<Host>标签内（通常是<Host name="localhost" ...>），添加RewriteValve的配置。

   <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> <!-- 添加以下Valve配置 --> <Valve className="org.apache.catalina.valves.rewrite.RewriteValve" /> <!-- 其他配置保持不变 --> ... </Host>

   保存文件。

2. 创建rewrite.config文件： 在需要测试的Web应用目录下创建WEB-INF/rewrite.config。我们以ROOT应用（即默认主页应用）为例。在Docker容器中，我们映射的webapps/ROOT/WEB-INF/目录下创建这个文件；如果是手动安装，路径是webapps/ROOT/WEB-INF/。rewrite.config内容如下：

   # 这是一条简单的重写规则，将 /test 重定向到 /index.jsp # 在漏洞版本中，攻击者可能利用规则匹配和后续处理逻辑的缺陷，即使不匹配此规则，也能触发路径遍历 RewriteRule ^/test$ /index.jsp [L]

   实操心得：在实际复现中，有时一条非常宽泛的规则（如RewriteRule .* - [L]）或者某些条件下规则匹配失败后的默认处理流程，更容易暴露出路径处理的问题。但为了演示的清晰性，我们先从简单配置开始。漏洞的本质是组件自身的处理逻辑缺陷，而非特定规则导致。

3. 重启Tomcat：

   • Docker容器：docker restart vulnerable-tomcat
   • 手动安装：运行bin/shutdown.sh再运行bin/startup.sh

3.3 构造攻击请求与验证漏洞

环境配置好后，我们就可以尝试构造恶意请求了。我们将使用curl命令行工具来发送请求，你也可以使用Burp Suite或Postman。

漏洞利用的核心是尝试访问Web应用目录之外的文件。在Linux系统中，一个经典的目标是/etc/passwd。在Tomcat的Web应用目录（通常是/usr/local/tomcat/webapps/ROOT）之外，尝试使用..来向上回溯。

尝试1：直接目录遍历首先，我们试试没有RewriteValve时，Tomcat核心是否已经拦截了这种请求。

curl -v "http://localhost:8080/../../../../etc/passwd"

正常情况下，Tomcat会返回400 Bad Request或者404 Not Found，因为核心规范化逻辑会拒绝这种明显超出范围的路径。你可能会看到类似The requested resource (/../../../../etc/passwd) is not available的404页面。

尝试2：利用RewriteValve的潜在处理路径现在，我们尝试在路径中插入一个可能被RewriteValve“特殊处理”的片段。根据漏洞原理，我们需要找到一个能“骗过”RewriteValve早期规范化，但又被Tomcat核心以不同方式解析的路径序列。一种常见的测试模式是使用/static/这样的常见前缀，或者结合一些编码。

# 尝试包含一个常见的静态资源路径前缀 curl -v "http://localhost:8080/static/../../../etc/passwd" # 尝试URL编码 curl -v "http://localhost:8080/static/%2e%2e/%2e%2e/%2e%2e/etc/passwd" # 尝试混合斜杠和编码 (Windows环境下可能测试不同的分隔符) curl -v "http://localhost:8080/static\..\..\..\..\etc\passwd"

重要提示：CVE-2025-55752的具体利用Payload并非公开的、简单的/../序列。Apache官方在公告中通常不会提供具体的攻击代码。上述命令是目录遍历漏洞的通用测试方法。真正触发CVE-2025-55752可能需要更精确的条件，例如特定的rewrite.config规则与特殊构造的URI相结合，使得RewriteValve内部产生的resourcePath变量包含非规范化部分。在没有确切PoC的情况下，复现的重点在于理解原理和验证修复。我们的目的是演示漏洞存在的环境，而非提供攻击武器。

尝试3：验证修复为了确认漏洞存在，最好的对比方法是搭建一个已修复的版本。我们去下载Tomcat 9.0.95（假设该版本已包含修复）或更新版本，重复上述配置和测试步骤。在修复版本中，所有试图通过RewriteValve进行目录遍历的请求都应该被坚定地拒绝，并返回400或404错误。

3.4 复现过程中的关键观察点与记录

在复现过程中，不要只关注是否成功读到/etc/passwd。更重要的是观察Tomcat的日志和行为，这能帮你深入理解漏洞触发点。

1. 查看Tomcat访问日志：检查logs/localhost_access_log.*.txt，观察Tomcat记录下来的请求URI是什么。如果RewriteValve处理前后URI不一致，这里可能会有线索。
2. 查看Catalina输出日志：关注logs/catalina.out或logs/localhost.yyyy-MM-dd.log，看是否有异常栈信息抛出。有时漏洞触发会导致NullPointerException、IllegalArgumentException或资源未找到的警告信息，这些信息可能隐含了路径处理的过程。
3. 使用调试模式（进阶）：如果你需要彻底分析，可以下载Tomcat源码，在IDE中远程调试。在org.apache.catalina.valves.rewrite.RewriteValve类的invoke方法以及相关的RewriteRule逻辑处设置断点，单步跟踪requestURI和重写后路径的变化过程。这是理解漏洞根源最直接的方式。

4. 漏洞修复方案与安全加固实践

复现漏洞是为了最终修复它。Apache Tomcat团队已经发布了修复版本。对于使用者来说，我们有清晰的上中下三策。

4.1 官方修复方案：升级Tomcat版本

这是最根本、最推荐的解决方案。请根据你当前使用的Tomcat主版本，升级到以下或更高版本：

• Tomcat 11.x用户：升级至11.0.2或更高版本。
• Tomcat 10.1.x用户：升级至10.1.27或更高版本。
• Tomcat 9.x用户：升级至9.0.95或更高版本。
• Tomcat 8.5.x用户：升级至8.5.101或更高版本。

升级前，务必在测试环境充分验证你的应用与新版本Tomcat的兼容性。可以从官网下载新版，替换安装目录，并迁移conf、webapps和lib（自定义JAR）等目录。

4.2 临时缓解措施：禁用或严格审查RewriteValve

如果因客观原因无法立即升级，可以考虑以下临时方案：

1. 禁用RewriteValve：如果业务并非强依赖URL重写功能，最直接的办法就是注释掉或删除server.xml中对应的<Valve className="org.apache.catalina.valves.rewrite.RewriteValve" />配置行，然后重启Tomcat。这是最快速的止血方式。
2. 严格审查rewrite.config规则：仔细检查WEB-INF/rewrite.config中的每一条规则。确保规则的目标路径（RewriteRule的右侧部分）是明确的、相对安全的，避免使用可能被用户输入影响的变量（如$1,%{QUERY_STRING}）直接拼接成文件系统路径。对于用户提供的路径参数，必须进行严格的校验和过滤。
3. 在反向代理层做重写：考虑将URL重写逻辑迁移到前置的Nginx或Apache HTTP Server中。这些Web服务器经过更长时间的安全考验，其重写模块（如ngx_http_rewrite_module）通常有更严格的默认安全策略。同时，这也能减轻Tomcat的处理负担。

4.3 长期安全加固配置建议

除了应对特定漏洞，建立良好的Tomcat安全配置习惯更为重要。

• 以非特权用户运行Tomcat：永远不要以root或Administrator身份运行Tomcat服务。创建一个专用的、权限最低的系统用户（如tomcat）来运行Tomcat进程。这样即使发生目录遍历，攻击者能读取的系统文件范围也受到极大限制。

  # Linux 示例 useradd -r -m -d /opt/tomcat -s /bin/false tomcat chown -R tomcat:tomcat /opt/tomcat sudo -u tomcat /opt/tomcat/bin/startup.sh

• 加固server.xml配置：
  • 移除或注释掉不必要的连接器（Connector），如AJP连接器（默认8009端口），如果未使用的话。
  • 在<Host>或<Context>中考虑设置deployOnStartup="false"和autoDeploy="false"，防止恶意WAR包被自动部署。
  • 确保allowLinking和crossContext等属性设置为false（除非有明确需求）。
• 定期更新与安全审计：订阅Apache Tomcat的安全公告邮件列表。定期对生产环境的配置进行安全审计，检查是否有不必要的Valve被启用，规则文件是否被篡改。可以使用自动化安全扫描工具对Tomcat服务进行漏洞扫描。

5. 从CVE-2025-55752延伸的Web安全思考

每一次漏洞复现，都应该是我们反思和提升安全架构意识的机会。CVE-2025-55752虽然是一个具体的组件漏洞，但它反映出的是一类经典的安全问题。

边界信任与输入验证的层层失守：Tomcat核心对路径规范化有严格检查，但RewriteValve作为一个“内部边界”组件，其输出没有被核心同等信任。这提醒我们，在系统设计时，任何来自上游组件、用户输入或配置文件的数据，在到达核心业务逻辑或敏感操作（如文件IO、数据库查询、命令执行）之前，都必须经过本模块的、独立的、严格的有效性验证和净化。不能假设上游已经做好了所有安全检查。

默认安全（Secure by Default）原则的缺失：RewriteValve在早期版本中，或许为了兼容性或者灵活性，在路径处理上留下了模糊空间。一个更安全的设计是，默认情况下，重写引擎应拒绝任何产出路径中包含..或尝试跳出docBase的规则匹配结果。安全特性应该是开箱即用的默认行为，而非需要用户手动配置的选项。

安全配置的复杂性：rewrite.config的语法虽然强大，但也增加了配置的复杂性和出错概率。对于大多数应用，是否真的需要如此复杂的服务端重写？很多URL美化、路由转发的工作，完全可以由更擅长此道的前端框架（如React Router, Vue Router）或专门的反向代理（Nginx）来更安全、更高效地完成。在Tomcat层，应遵循“最小功能”原则，只开启业务必需的特性。

漏洞复现的价值远不止于“利用”：作为开发或运维人员，我们复现漏洞的目的不是为了攻击，而是为了真正理解漏洞产生的根源。通过搭建环境、跟踪代码、观察日志，你能直观地看到一行配置、一段逻辑如何导致整个防线崩溃。这种理解远比读一份漏洞通告摘要深刻得多。它帮助你在编写代码、评审配置时，能本能地识别出类似的危险模式。

最后，处理这个漏洞的过程也让我再次审视了团队的安全流程。像RewriteValve这样的非默认功能，它的引入是否经过了评审？它的配置规则是否被当作代码一样进行版本管理和同行审查？生产环境使用的Tomcat版本是否有自动化的漏洞扫描和升级预警？CVE-2025-55752是一个及时的提醒，安全是一个持续的过程，它贯穿于技术选型、开发、配置、部署和运维的每一个环节。