Spring Boot升级Tomcat修复CVE-2024-21733实战

上周例行安全扫描的时候报告里冒出一个编号CVE-2024-21733指向Apache Tomcat。我第一反应是去查手头Spring Boot项目的依赖树果然内置的Tomcat版本正好落在受影响区间里。这个场景在Spring Boot项目里太常见了——安全公告总是比默认依赖版本快半拍尤其当项目没有及时跟进Spring Boot小版本的时候。这篇文章就把这次修复的完整过程拆开讲清楚从漏洞影响判断、Spring Boot修改Tomcat版本的核心原理、Maven/Gradle里的具体改法再到升级后的验证和坑点记录。正在处理这个CVE的开发者、测试和运维同学直接按流程操作即可大部分项目一个小时内能搞定。1. 先搞明白CVE-2024-21733 到底是个什么问题1.1 漏洞本质上是什么CVE-2024-21733是Apache Tomcat在2024年初披露的一个HTTP/1.1协议处理层安全漏洞。Tomcat在解析不完整的请求体时由于内部状态机对请求边界判断存在缺陷可能把一条请求的残余内容当作新请求来处理。这类问题在安全领域有个专门的名字请求走私Request Smuggling。攻击者可以利用它构造一个“看起来正常”的请求让前置代理、网关和后端Tomcat对请求边界的理解不一致从而绕过防护规则。受影响版本区间是明确的Apache Tomcat 9.0.0-M1到9.0.85、10.1.0-M1到10.1.17、11.0.0-M1到11.0.0-M11。修复版本分别对应9.0.86、10.1.18和11.0.0-M12。Spring Boot项目使用内嵌Tomcat时版本来源基本是spring-boot-starter-tomcat这条依赖链很多项目长时间不升级落在受影响区间内的概率是相当高的。提示请求走私类漏洞的利用前提通常需要应用前面有代理、网关或负载均衡但这种漏洞不能等条件出现再修。安全基线要求的是版本合规只要安全公告发布了就必须处理。1.2 影响范围与利用条件很多同事看到安全公告第一句话就是问“我们的项目到底危不危险”我的判断方法是标准的三步。第一步确认Tomcat实际版本。Maven项目执行mvn dependency:tree找到tomcat-embed-core这一行记下版本号Gradle项目执行./gradlew dependencies --configuration runtimeClasspath | grep -i tomcat。第二步把版本号和受影响区间做对比。第三步看应用的部署形态。Spring Boot最常见的部署方式是打成可执行Jar包、自带内嵌Tomcat这种情况修改pom里的版本再重新打包就能修复如果是WAR包部署到独立Tomcat服务器上那要升级的是服务器上的Tomcat安装包改pom只是第一步。这里有个特别容易踩的坑不要只看Spring Boot大版本号。Spring Boot 2.x默认使用Tomcat 9.xSpring Boot 3.x默认使用Tomcat 10.x但这只是大方向的对应关系。Spring Boot不同小版本内置的Tomcat小版本可能完全不同比如同一个2.7分支早期版本和后期修复版本内置的Tomcat小版本差距很大。所以判断是否受影响必须以依赖树实际解析出来的版本号为准不要凭大版本号猜测。1.3 如何快速确认当前运行版本除了依赖树之外我习惯在测试环境临时加一个接口直接读取Tomcat内置的版本信息作为运行时证据。import org.apache.catalina.util.ServerInfo; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RestController; RestController public class TomcatVersionController { GetMapping(/diagnose/tomcat-version) public String getTomcatVersion() { return ServerInfo.getServerInfo(); } }请求这个接口返回内容类似Apache Tomcat/10.1.17。把这个返回值与依赖树对比一下如果一致说明实际生效的版本就是依赖树里看到的版本。如果项目因为某些奇怪的原因同时存在多个Tomcat版本这个接口返回的可能不是依赖树上最新的那个这种情况就说明依赖冲突还没有解决修了也未必生效。这个验证方法只建议在测试环境用生产环境不要加这种临时接口直接用安全扫描工具确认即可。2. 修改 Tomcat 版本的几种思路为什么我推荐先看 Spring Boot 版本2.1 三种修复方案的优缺点对比动手之前先花五分钟想清楚方案比直接改pom更省时间。围绕CVE-2024-21733常见的修复路线有三条。修复方案操作复杂度风险程度适用场景覆盖tomcat.version属性低中低Spring Boot版本较新只落后于Tomcat小版本升级整个Spring Boot版本中偏高Spring Boot版本老旧希望一次补齐多个旧依赖更换Web容器如Undertow高高仅为修CVE不建议换容器引发的新问题远多于收益从工程角度讲单纯为了CVE-2024-2173390%以上的场景选第一条就够了。如果项目Spring Boot版本已经很老那就选第二条借这次机会把一批旧依赖一起补齐。第三条一般不建议除非项目本来就在做容器迁移顺手完成。2.2 Spring Boot 的依赖版本覆盖机制很多第一次遇到这个问题的同事会问Spring Boot不是已经把依赖版本锁死了吗为什么pom里写一个属性就能改Tomcat版本这里要把原理讲清楚。Spring Boot官方的spring-boot-starter-parent内部引入了spring-boot-dependencies这是一个BOMBill of Materials。BOM通过dependencyManagement统一管理数百个组件版本而这些版本号并不是硬编码在依赖声明中的而是先定义了一组属性比如tomcat.version9.0.83/tomcat.version再在依赖管理里写version${tomcat.version}/version。Maven解析时会先读取当前pom里声明的属性再代入依赖版本计算。因此当项目自己的pom里重新定义同名属性tomcat.version时就覆盖了父POM中的默认值。所有引用这个属性的依赖包括tomcat-embed-core、tomcat-embed-el、tomcat-embed-websocket都会统一切换到新版本。这种机制设计出来就是为了方便使用方在特定情况下微调依赖版本。Gradle项目的原理一致只是写法不同ext[tomcat.version] 9.0.87Spring Boot Gradle插件在解析依赖管理信息时会优先读取ext中定义的属性值。理解了这套机制后面改起来心里就有底了也不容易被各种表面报错吓到。2.3 方案选型的核心判断依据我在实际选择时主要看两个条件当前Spring Boot版本的“年龄”以及项目里有没有其他隐藏的依赖风险。如果当前Spring Boot是较新的版本比如3.2.x或2.7.x的后期小版本只是Tomcat小版本落后导致中招直接覆盖tomcat.version是最优解。新版本Spring Boot对Tomcat的适配已经很成熟小版本升级相对安全。如果当前Spring Boot是两到三年以前的版本比如2.4.x或2.5.x此时受影响的往往不只是Tomcat。与其反复打补丁不如规划一次Spring Boot版本升级。虽然回归工作量更大但安全收益是整体性的也能顺便解决其他组件的已知问题。还有一种场景要特殊提醒如果项目的实际部署方式是WAR包放到外部Tomcat容器里那么上面讨论的所有内嵌Tomcat修改方案在生产环境都不会生效。这种情况必须同步处理外部Tomcat安装包或者改变部署架构。这个问题最好在动手前就与运维确认清楚否则pom改了半天生产环境扫描结果依然会报漏洞。3. 实战Maven/Gradle 项目修改 Tomcat 版本全流程3.1 第一步确认当前环境版本先从确认事实开始。拿一个Maven项目举例假设当前使用的是Spring Boot 2.7.18依赖树关键部分大致是这个样子[INFO] - org.springframework.boot:spring-boot-starter-web:jar:2.7.18:compile [INFO] - org.springframework.boot:spring-boot-starter-tomcat:jar:2.7.18:compile [INFO] - org.apache.tomcat.embed:tomcat-embed-core:jar:9.0.83:compile [INFO] - org.apache.tomcat.embed:tomcat-embed-el:jar:9.0.83:compile [INFO] - org.apache.tomcat.embed:tomcat-embed-websocket:jar:9.0.83:compile9.0.83这个版本就在CVE-2024-21733的受影响区间内。这一步的意义在于把“当前实际版本”和“目标修复版本”之间的差距搞清楚后面修改时才知道自己到底要跨多大步子。Gradle项目则执行./gradlew dependencies --configuration runtimeClasspath | grep -i tomcat输出中同样会列出tomcat-embed-core等条目的版本号。无论哪种构建工具这一步都不能省略。3.2 第二步用属性覆盖 Tomcat 版本号确认当前版本后Maven项目在pom.xml的properties区域添加目标版本。从官方公告看9.0.86是第一个修复版本但实际我操作时会选择更新一点的稳定版比如9.0.87或当时可用的最新9.0.x。这里的逻辑很简单修复版本之后通常会继续修复其他问题直接选较新的版本可以减少后续再次升级的频率。properties java.version1.8/java.version tomcat.version9.0.87/tomcat.version /propertiesGradle项目在build.gradle顶部添加ext[tomcat.version] 9.0.87这里要特别说明一个情况如果项目不是继承spring-boot-starter-parent而是通过dependencyManagement直接导入spring-boot-dependenciesBOM那么靠属性覆盖不一定生效。因为BOM内部解析属性时使用的是BOM模型里定义的默认属性项目重新声明的同名属性不一定会传入。遇到这种情况两种处理办法一是在项目的dependencyManagement中显式声明Tomcat相关依赖并指定目标版本二是在使用Tomcat的依赖上直接写死version。推荐第一种第二种在多模块项目里容易造成版本混乱。3.3 第三步重新构建与验证版本修改完成后执行mvn clean package然后再次运行依赖树命令mvn dependency:tree | grep -i tomcat正常情况下三个核心依赖都会变成目标版本。这里有一个需要警惕的现象如果依赖树里同时出现了tomcat-embed-core:9.0.83和tomcat-embed-core:9.0.87两行说明项目某处直接依赖了旧版本或者某个第三方依赖传递引入了旧版本。此时不能直接发布必须先解决冲突否则类路径上优先加载哪一版并不受你控制。Gradle项目重新构建./gradlew clean build ./gradlew dependencies --configuration runtimeClasspath | grep -i tomcat构建成功后启动应用调用上面新建的/diagnose/tomcat-version接口返回内容应该类似Apache Tomcat/9.0.87。依赖树和运行时接口两个证据都对上了这一步才算真正完成。3.4 第四步启动应用与回归测试清单版本升级后容器行为存在小概率变化启动后必须做一轮回归。这里分享一个我常用的清单。基础HTTP请求GET、POST、PUT、DELETE接口能否正常返回响应头正常大请求体构造一次较大的POST请求确认Content-Length和分块传输处理正常文件上传如果项目有文件上传功能确认multipart配置解析正确WebSocket如果项目用到WebSocket确认握手和消息收发正常JSP支持使用JSP模板的项目确认页面渲染正常JSTL标签没有异常自定义Filter和Interceptor确认执行顺序和原有逻辑一致Session和Cookie确认会话创建、Cookie传递与升级前一致小版本升级通常不需要全量回归但核心业务链路必须过一遍。如果组织内配置了安全扫描流水线最好在预发环境触发一次扫描用工具结果来确认漏洞状态已经变化。这个环节别省。4. 升级 Tomcat 版本后常见的兼容性问题和排查方法4.1 启动时报 ClassNotFoundException / NoSuchMethodError升级后启动直接报错最可能出现的原因就是依赖树里混入了多个Tomcat版本或者Tomcat相关组件之间版本不一致。举个例子tomcat-embed-core升到了9.0.87但某个依赖里显式引入了tomcat-embed-websocket:9.0.83两个版本并存时就可能出现NoSuchMethodError。排查思路很固定。第一步跑完整依赖树用mvn dependency:tree -Dverbose查看所有Tomcat相关依赖的出现位置。第二步打开pom.xml搜索是否存在tomcat-embed这类显式依赖声明有的话对比版本。第三步把多余的显式依赖删除或者在各依赖上添加exclusions排除旧版本。如果项目里没有显式声明那多半是某个第三方starter传递引入的同样按排除方式处理。4.2 某些 Filter/WebSocket/JSP 功能出现异常我实际遇到过一个升级后WebSocket连接失败的案例根因并不在Tomcat本身而是项目里一个老版本的WebSocket扩展包对Tomcat内部类做了强依赖。Tomcat小版本升级通常不做破坏性变更但类内部的行为细节会有差异这种间接依赖就容易出问题。遇到这类情况我的建议是不要在Tomcat版本上来回试先回滚到原版本确认问题是否存在再判断是不是升级引发的。如果确实由升级引起接下来评估两个方向一是替换掉底层依赖老版本Tomcat内部行为的第三方扩展二是整体升级Spring Boot版本。硬要在旧Spring Boot上配新Tomcat有时候会陷入兼容性连环坑。4.3 依赖树中同时存在多个 Tomcat 版本这是最隐蔽的一个问题。表面看pom里设置了tomcat.version构建也正常但实际运行的类可能来自另一个老旧传递依赖。原因是Maven在解析依赖冲突时会按依赖最短路径优先规则选择一个版本这个被选中的版本未必是你想要的。举个例子项目里有两个模块A模块直接依赖了tomcat-embed-core:9.0.83根项目pom通过属性和BOM把传递版本升到9.0.87但A模块的直接依赖在解析优先级上更高最终生效的还是9.0.83。解决办法是用mvn dependency:tree -Dverbose找到旧版本的完整引入路径然后在对应依赖上添加排除配置或者调整模块结构让版本管理更集中。处理完再用/diagnose/tomcat-version接口实测一次双保险。4.4 部署架构层面容易忽略的两个事项第一件是内嵌容器和外部容器的区分。很多团队虽然用Spring Boot开发但最终部署是把WAR包丢到服务器上单独安装的Tomcat里。这种架构下修改pom里的Tomcat版本只能影响开发期和本地启动生产环境实际运行的是外部Tomcat。如果外部Tomcat版本没有同步升级安全扫描结果依然会显示漏洞。正确做法是两者同时处理pom版本对齐到目标版本外部Tomcat安装包也升级到对应的安全版本。第二件是微服务场景。一个业务系统往往有十几个Spring Boot服务只升级其中一两个整体安全扫描依然会暴露问题。修复应该是一次批量操作至少在同一个迭代里把所有受影响服务统一升级。建议做一个清单按服务名、当前Tomcat版本、目标版本三列记录逐个确认构建、发布后再在网关维度做一次整体扫描确认。5. 生产环境升级的实操心得与风险控制5.1 升级前做的几件准备工作先说准备。别直接在生产环境改pom这句话应该不用强调。我一般会在版本控制系统里基于当前release分支拉一个fix分支在分支上完成pom修改跑一遍完整的自动化测试尤其是接口测试和集成测试然后构建出新制品在预发环境部署验证。如果组织内有安全扫描流程可以在预发环境触发一次扫描确认CVE-2024-21733的状态从“存在”变为“已修复”。这个反馈比“应该改好了”要可靠得多。另外还要检查版本管理系统里的CI/CD配置确认构建产物确实是从当前fix分支产出避免出现分支发错、验证了半天测的还是旧包的情况。5.2 灰度发布与回滚方案生产发布要小步快跑。我个人的做法是先挑一个非核心服务发布观察半小时到一小时确认日志正常、错误率没有上升再逐步扩展到其他服务。如果整个系统只有一个服务那就选流量低峰期操作并且提前准备好回滚方案。使用tomcat.version属性覆盖的方式回滚非常简单把属性值改回原来的版本重新构建发布即可。所以发布前最好保留一个构建好的原版本制品万一升级后出现问题可以直接用原制品回滚不需要重新构建。这个“留一手”的习惯能让整个处理过程从容很多。5.3 后续定期检查版本更新的建议修完这次漏洞之后长期值得坚持的一件事是把依赖版本检查自动化。代码托管平台的依赖扫描功能、CI流水线里集成OWASP Dependency-Check都可以在依赖引入新漏洞时自动提醒。不少团队都是等安全扫描报告“偶然”发现问题才被动处理这种模式在漏洞高频出现的当下确实有点冒险。我现在习惯在每个迭代发布前跑一次依赖安全扫描把新增漏洞统一过一遍。高危并有修复版本的直接排进当前迭代低危或者暂时没有修复版本的记录下来持续跟踪。这个习惯比单独修复一次CVE的价值更大。下次再有类似CVE-2024-21733出现时可能安全扫描工具早就发通知了根本不用等到人工撞见。升级Tomcat只是这次修复的一个动作建立可持续的依赖监控机制才是真正能降低下次踩坑概率的长期方案。