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?id123看起来不太友好也不利于SEO。通过配置RewriteValve你可以将它重写为https://example.com/product/123。第二请求转发和路由。在有些架构中你可能希望将所有对特定路径的请求都转发给后端另一个应用或Servlet处理这时也可以用RewriteValve来实现而不是依赖前端Web服务器如Nginx/Apache HTTPD的重写规则。它的配置通常放在Tomcat的conf/server.xml文件里在对应的Host或Context标签内添加。一个最简单的配置示例如下Valve classNameorg.apache.catalina.valves.rewrite.RewriteValve /然后你需要在Web应用的WEB-INF目录下创建一个rewrite.config文件里面用类似Apache mod_rewrite的语法来定义重写规则。例如一条将/product/123重写到/product?id123的规则可能长这样RewriteRule ^/product/([0-9])$ /product?id$12.2 漏洞根源路径规范化处理的逻辑缺陷那么CVE-2025-55752这个目录遍历漏洞到底出在哪里呢核心问题出在RewriteValve对请求URIrequestURI和重写目标路径的处理逻辑上特别是在进行“路径规范化”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之外的位置。想象一下这个流程攻击者发送请求GET /static/../../../etc/passwd HTTP/1.1请求到达TomcatRewriteValve介入处理。RewriteValve的规则引擎在处理这个URI时可能因为某条规则甚至是默认或错误的配置匹配成功决定不对其进行重写或者重写成一个仍然包含..的路径。关键点RewriteValve在将这个可能仍不规范的路径传递给Tomcat核心资源获取逻辑时没有触发与核心逻辑同等严格的规范化检查或者传递的上下文信息有误。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.shLinux或bin/startup.batWindows。3.2 配置RewriteValve与诱导规则默认情况下RewriteValve是没有启用的。我们需要手动配置它并且为了演示漏洞我们故意设置一条可能“放大”问题的规则。实际上即使是一条看似无害的规则在漏洞版本中也可能成为利用的跳板。编辑server.xml 进入Tomcat的conf目录找到server.xml文件。在Host标签内通常是Host namelocalhost ...添加RewriteValve的配置。Host namelocalhost appBasewebapps unpackWARstrue autoDeploytrue !-- 添加以下Valve配置 -- Valve classNameorg.apache.catalina.valves.rewrite.RewriteValve / !-- 其他配置保持不变 -- ... /Host保存文件。创建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]或者某些条件下规则匹配失败后的默认处理流程更容易暴露出路径处理的问题。但为了演示的清晰性我们先从简单配置开始。漏洞的本质是组件自身的处理逻辑缺陷而非特定规则导致。重启TomcatDocker容器docker restart vulnerable-tomcat手动安装运行bin/shutdown.sh再运行bin/startup.sh3.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的日志和行为这能帮你深入理解漏洞触发点。查看Tomcat访问日志检查logs/localhost_access_log.*.txt观察Tomcat记录下来的请求URI是什么。如果RewriteValve处理前后URI不一致这里可能会有线索。查看Catalina输出日志关注logs/catalina.out或logs/localhost.yyyy-MM-dd.log看是否有异常栈信息抛出。有时漏洞触发会导致NullPointerException、IllegalArgumentException或资源未找到的警告信息这些信息可能隐含了路径处理的过程。使用调试模式进阶如果你需要彻底分析可以下载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如果因客观原因无法立即升级可以考虑以下临时方案禁用RewriteValve如果业务并非强依赖URL重写功能最直接的办法就是注释掉或删除server.xml中对应的Valve classNameorg.apache.catalina.valves.rewrite.RewriteValve /配置行然后重启Tomcat。这是最快速的止血方式。严格审查rewrite.config规则仔细检查WEB-INF/rewrite.config中的每一条规则。确保规则的目标路径RewriteRule的右侧部分是明确的、相对安全的避免使用可能被用户输入影响的变量如$1,%{QUERY_STRING}直接拼接成文件系统路径。对于用户提供的路径参数必须进行严格的校验和过滤。在反向代理层做重写考虑将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中考虑设置deployOnStartupfalse和autoDeployfalse防止恶意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是一个及时的提醒安全是一个持续的过程它贯穿于技术选型、开发、配置、部署和运维的每一个环节。