说实话这个洞我一开始没太当回事直到某次安全扫描把报告甩到群里标题写着“CVE-2024-38819 目录遍历”我才愣了一下。毕竟一直在 Spring Boot 项目里直觉第一反应就是官方都修复了升个版本不就完了结果一查才意识到这里面的“特定条件下”几个字才是整个排查过程最折腾人的地方。它不是那种“只要用了 Spring Boot 就中招”的漏洞而是跟你项目的路由写法直接相关。如果你现在也正在处理这个编号或者安全团队让赶紧修我建议把这篇看完能少走不少弯路。1. CVE-2024-38819 到底打在了哪里函数式路由的路径校验盲区1.1 传统控制器与函数式路由在路径解析上的差异很多项目现在用的是传统写法RestControllerRequestMapping(/xxx)。这种写法下Spring MVC 的资源处理链路是经过ResourceHttpRequestHandler的它内部有一套比较完整的资源解析器链PathResourceResolver只是其中一环前后还有别的校验所以在传统接口里../这种目录穿越请求基本会被拦得比较死。CVE-2024-38819 影响的是另外一套东西——WebMvc.fn和WebFlux.fn也就是函数式路由。这套风格用RouterFunction来定义接口写起来确实简洁比如Bean public RouterFunctionServerResponse route() { return RouterFunctions.route() .GET(/api/hello, request - ServerResponse.ok().body(hello)) .build(); }静态资源也能用函数式方式暴露Bean public RouterFunctionServerResponse staticResources() { return RouterFunctions .resources(/static/**, new ClassPathResource(static/)); }问题就出在这个resources(/static/**, ...)这类路径映射上。函数式路由在把请求转发给资源处理器时它内部对路径的解析、解码、校验顺序跟传统ResourceHttpRequestHandler并不完全一致。简单说它在某些环节里没有对“路径片段是否为..”做强制收紧这就给目录遍历留下了口子。1.2 触发条件拆解RouterFunction 与静态资源映射缺一不可这个漏洞不是说你引入了函数式路由就完蛋它还需要满足两个条件接口是通过RouterFunction暴露的并且处理的是资源请求比如静态文件、下载文件。请求路径可以被攻击者控制并且包含了 URL 编码后的../片段。举个例子假设项目里用RouterFunctions.resources(/static/**, location)暴露了静态资源攻击者请求/static/%2e%2e/%2e%2e/application.properties这里的%2e%2e是..的 URL 编码形式%2f是/的编码形式。在老版本代码里函数式路由内部把请求路径解码后直接拿去定位资源却没有像传统资源处理器那样在每一层解析里都检查..片段于是文件读取就跳出了静态资源目录跑到了项目目录甚至系统目录。为什么很多扫描器只在特定条件下报这个 CVE因为它不是通用的RequestMapping注解接口而是函数式路由这一条链路上的问题。如果你项目里全是传统控制器没有RouterFunctions那这个漏洞大概率扫不到你头上。但问题是很多工程是“新旧混用”的老模块用注解新模块用了函数式路由这类项目恰恰最容易中招。路由方式是否受 CVE-2024-38819 影响传统RequestMapping/RestController不受该漏洞直接影响RouterFunction暴露业务接口不受直接影响RouterFunction暴露资源文件/静态文件受影响传统 resource handler 配置不受该漏洞直接影响1.3 官方版本范围与修复版本怎么对照官方公告里给出的修复版本大致是这样的Spring Framework 5.3.x 线需要升到 5.3.40 以上6.1.x 线需要升到 6.1.14 以上6.2.x 线上使用包含修复的正式发布版本。6.0.x 已经到了社区维护停止状态官方基本只让你往上升不推荐继续停留在 6.0 系列。在 Spring Boot 项目里情况要稍微绕一下。Boot 自己不会单独发一个“修复版本”它是通过内置的 Spring Framework 依赖版本来带修复的。所以你需要关注的不是“Boot 是否出了 CVE 公告”而是“Boot 默认管理的 Framework 版本是否已经落在修复范围内”。我当时用的是 Boot 3.2 系默认对应的 Framework 是 6.1.x所以修复的路径就是要么把 Boot 升到已经内置 Framework 6.1.14 的新补丁版要么单独把spring-framework.version属性覆盖到修复版本。这里我强烈建议优先升级 Boot而不是手动改 Framework 版本。2. 自测清单三分钟判断项目有没有踩中这个洞2.1 用 dependency:tree 查看真实依赖别凭记忆判断“我项目里应该没用到函数式路由”先把依赖树拉出来看一眼。Maven 项目直接执行mvn dependency:tree -Dincludesorg.springframework:*重点关注spring-webmvc、spring-webflux、spring-web这几个模块的版本号。如果是 Gradle 项目./gradlew dependencyInsight --dependency org.springframework:spring-web这里要特别提醒一句有些项目里你根本不知道自己间接引入了旧版 Spring。比如某个内部公共库传递依赖了旧的spring-webmvc而你的主 pom 用的是 Boot 管理Boot 的 BOM 并不能把别人传递进来的依赖强制覆盖掉除非你把版本在 dependencyManagement 里显式锁住。所以扫描器报“CVE-2024-38819 未修复”时第一件事不是改版本而是先定位是哪个模块引入了旧版本。2.2 代码层面检查有没有 RouterFunction依赖版本符合修复范围不代表万事大吉你还得看代码到底有没有用函数式路由。最快的方法rg -n RouterFunctions|RouterFunction|HandlerFunction src/main/java或者直接在 IDE 里全局搜RouterFunctions。如果没有任何结果说明项目大概率没有使用 WebMvc.fn / WebFlux.fn 的资源处理逻辑那这个漏洞跟你的运行时代码基本无关更多是依赖版本需要跟进。但这里有一个很容易漏的点有些接口是用函数式路由写的但暴露的不是资源文件而是 JSON 接口。这类也不会受到目录遍历影响。受影响的核心是那个router.resources(...)或者通过RouterFunction去转发Resource的地方。如果你的函数式路由只返回数据那不需要太担心。另外如果项目里同时存在老式的WebMvcConfigurer.addResourceHandlers配置这个漏洞不直接覆盖那种写法那套链路依然走ResourceHttpRequestHandler的完整校验。真正要排查的是RouterFunctions场景下的资源处理。2.3 在本地环境构造验证请求既然要确认有没有这个洞最直接的办法就是在本地测试环境打一个验证请求。这里强调一下别拿公网实例试更别拿生产环境试所有验证都在自己可控的环境里做。我当时是在本地调试端口上跑的并且读取的目标文件是项目自己的配置文件。假设项目里暴露了/static/**的静态资源路由本地端口是 8080验证命令可以这样curl -i --path-as-is http://127.0.0.1:8080/static/%2e%2e/%2e%2e/application.properties这里有个关键参数是--path-as-is。不加这个参数的话curl 会在发出请求前自己把/static/../application.properties规范化路径直接变成/application.properties那测的就不对味了。有了--path-as-iscurl 会原样发送这段带编码的路径让服务端去解析。如果返回 200 且 body 里出现了application.properties的内容说明确实存在问题。如果返回 404 / 400说明当前版本或者当前配置已经挡住了这类请求。除了单次编码%2e%2e%2f你还可以试双重编码curl -i --path-as-is http://127.0.0.1:8080/static/%252e%252e%252f%252e%252e%252fapplication.properties有些早期的目录遍历漏洞在单重编码被修复后双重编码还能绕过。Spring 这个 CVE 在修复版本里做了比较彻底的收紧两条请求都应该被拦下来才对。请求路径编码含义修复前预期修复后预期/static/../application.properties未编码可能被容器规范化404/static/%2e%2e/%2e%2e/application.properties单次 URL 编码可能命中漏洞404/400/static/%252e%252e%252f%252e%252e%252fapplication.properties双重 URL 编码少数情况能命中404/4003. 修复落地升级版本的正确姿势与临时缓解措施3.1 升级 Boot 而不是单独换 Framework我在处理这个 CVE 的时候一开始的方案是“只升级 spring-webmvc”后来发现这是个非常不推荐的做法。Spring Boot 的依赖管理是成体系的Boot parent 的dependencyManagement里锁定了所有 Spring 模块的版本。如果你手动把某个模块的版本改了轻则依赖树里出现多个不一致的 Spring jar 包重则启动时直接报方法不兼容的问题。正确做法是直接升级 Spring Boot 版本。比如我那个项目从 Boot 3.2.x 拉到了 3.3.x 的最新补丁版Boot 内置的 Framework 版本自然就超过了 6.1.14。具体升级时把父 pom 里的版本改成自己依赖管理最新可用版parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.3.6/version relativePath/ /parent这里的版本号只是个示例实际升级前先去官方仓库看可用的最新补丁版。升级后不要只盯着spring-webmvc有没有变spring-core、spring-context、spring-web都要一起对齐。最稳妥的操作是执行一次干净构建mvn clean verify然后在启动日志里看 banner 下方的 Spring 版本号确认已经是修复后的版本。3.2 如果暂时升不了级临时过滤器怎么加有些项目确实有特殊情况比如依赖的公共库还没做兼容或者升级窗口不在当前迭代这种情况你至少要做一层临时缓解。一个比较通用的方式是在 Servlet 链路上加一个前置过滤器对请求路径里的目录遍历特征做拦截。我当时根据自己的项目现状写了一个过滤器思路是这样的拿到原始 URI做一次 URL 解码然后检查解码结果里是否包含../、..\\这类特征。如果有直接返回 400。Component Order(Ordered.HIGHEST_PRECEDENCE) public class PathTraversalProtectionFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest httpRequest (HttpServletRequest) request; String requestUri httpRequest.getRequestURI(); String decoded URLDecoder.decode(requestUri, StandardCharsets.UTF_8); if (decoded.contains(../) || decoded.contains(..\\) || decoded.contains(/./) || decoded.contains(%2e) || decoded.contains(%252e)) { ((HttpServletResponse) response).sendError(HttpServletResponse.SC_BAD_REQUEST); return; } chain.doFilter(request, response); } }这里有几个细节要注意第一为什么用getRequestURI()而不直接用getPathInfo()因为在不同容器上路径信息的分法不一样直接拿 URI 最稳妥。第二URLDecoder.decode会把转成空格不过这里只是判断路径特征不太受影响。第三双重编码的问题要小心。%252e%252e%252f解码一次后是%2e%2e%2f如果你只检查原始 URI 里的../是检查不到的所以我还额外判断了解码结果里是否还存在%2e这种残留特征。实际生产环境的复杂度还会更高但这个过滤器作为“临时挡板”是够用的。3.3 用属性覆盖 Framework 版本的临时方案如果是 Spring Boot 项目又没法立刻升级 Boot 版本还可以利用 Boot 的依赖管理属性做临时修复。Spring Boot parent pom 里暴露了spring-framework.version这个属性允许你单独控制 Spring Framework 的版本号properties spring-framework.version6.1.14/spring-framework.version /properties这个方案比手动改某个 jar 包版本要靠谱一些因为它至少没有绕过 Boot 的 BOM 管理只是覆盖了整个 Framework 家族。但不要长期依赖这个方式。Boot 版本和 Framework 版本之间有潜在兼容性问题比如 Boot 3.2 官方配套的是 6.1.x你硬把它改成 6.1.14 问题不大但改成 6.2.x 就不一定了。所以我的建议是属性覆盖只适合救急升级计划还是要排上日程。4. 升级后复测与自动化回归别让漏洞换个姿势回来4.1 同一条 curl 的前后对比版本升级完成后我最关心的就是之前那条能返回文件内容的请求现在会变成什么状态。操作步骤很简单重新构建项目并启动服务。再次执行前面提到的 curl 命令。看响应状态码和响应体。修复后/static/%2e%2e/%2e%2e/application.properties应该返回 404 或者被框架直接拒绝响应体里不再出现文件内容。我在实际验证时还顺手试了下面这几种组合curl -i --path-as-is http://127.0.0.1:8080/static/..%2f..%2fapplication.properties curl -i --path-as-is http://127.0.0.1:8080/static/%2e%2e%2f%2e%2e%2fapplication.properties curl -i --path-as-is http://127.0.0.1:8080/static/..%5c..%5capplication.properties全部被拦截才算放心。这里有个经验之谈修复类 CVE 的验证不能只看一条 payload 就收工。目录遍历类的 payload 变体非常多尤其要注意反斜杠\的编码形式也就是%5c。虽然 Linux 下反斜杠不是路径分隔符但 Windows 容器上..\\可能被当成路径穿越。4.2 把漏洞回归写进自动化测试很多项目的安全修复都是“改了跑通了上线了再没人管”。这种做法最大的隐患是下次有某个同事重新拉了旧分支或者公共依赖被误降版本漏洞可能悄无声息地又回来了。所以我建议把这次验证固化到自动化测试里。如果你的项目用的是 Spring Boot 的MockMvc可以写一个简单的回归用例直接在测试里断言“目录穿越请求必须被拒绝”Test void pathTraversalShouldBeRejected() throws Exception { mockMvc.perform(get(/static/%2e%2e/%2e%2e/application.properties)) .andExpect(status().isNotFound()); }有一点要提前说明MockMvc在某些情况下会把请求路径做一定程度的规范化不一定能百分百复现生产环境上真实的绕过场景所以这个测试更适合作为“回归基线”而不是“唯一验证标准”。真正上线前最好还是在独立的测试环境里用真实 HTTP 请求做一次端到端验证。4.3 升级后扫描平台可能出现的误报与漏报安全扫描平台给出的结果不一定完全反映实际运行状态。有些扫描器是基于版本号判断的只要它检测到旧版本就会报“未修复”哪怕你的代码里根本没用函数式路由也会被标记。这类误报处理起来很简单在复测时把扫描结果和实际情况一起附上说明项目并未使用受影响功能然后升级版本后重新扫描。反过来也要提防漏报。有些扫描器只发一两个固定 payload如果你的接口用的是双重编码或者大小写混写扫描器可能测不出来。所以我在复测时会手动补测几个变体宁可多试几条也不要让问题藏在扫描盲区里。5. 目录遍历类漏洞的通用防御习惯这次修的不仅是 Spring5.1 所有“下载文件”功能都可能出现同类问题CVE-2024-38819 是 Spring 的漏洞但目录遍历这一类问题绝不仅是框架的问题。我见过太多业务代码里直接做文件下载的接口写法基本就是String filePath uploadDir File.separator fileName; return ResponseEntity.ok(Files.newInputStream(Paths.get(filePath)));这代码如果fileName是用户传的那它的风险不比这次 Spring 的漏洞小。攻击者把fileName传成../../../etc/passwd文件流照样能打开。所以借着修这个 CVE 的机会我建议把所有涉及文件读取的接口都盘一遍。5.2 路径校验的正确姿势与常见反模式一个常见的反模式是“黑名单过滤”遇到../就拒绝。这种校验很容易被编码绕过比如%2e%2e%2f、双重编码、Unicode 半角/全角字符等。更稳妥的方式是白名单思维加路径规范化校验。具体来说把用户输入先解析成Path然后做normalize()再判断最终路径是否仍然位于允许的目录内public static Path safeResolve(Path baseDir, String userInput) { Path target baseDir.resolve(userInput).normalize(); if (!target.startsWith(baseDir)) { throw new IllegalArgumentException(非法路径); } return target; }normalize()会把..和.片段消除掉。消除之后再判断startsWith(baseDir)如果目标目录跑到了白名单目录外面直接拒绝。这是目前比较推荐的校验方式。另外文件下载接口最好连“路径”都不要让用户传。前端传文件 ID 或者业务主键后端通过 ID 查表得到真实文件名这样用户完全没有机会注入路径。我在项目里推进的规范就是能查表就不拼路径能传 ID 就不传文件名。5.3 给新代码加一条安全检查清单我在团队内部定了一个简单的自查清单每次新增文件上传下载、静态资源暴露相关接口时都过一遍检查项推荐做法用户输入是否直接参与文件路径拼接改为传 ID/业务键由后端映射真实路径是否允许文件名里带路径分隔符不允许统一用PathAPI 处理是否对最终路径做了normalize()必须做且校验startsWith(baseDir)是否暴露了超出预期的静态资源目录只暴露独立目录不使用file:///根路径是否依赖黑名单过滤../不依赖改用白名单 路径规范化这些习惯说起来简单但真正落地的时候项目里总会冒出一些历史代码不遵守。借着修复一个 CVE 的契机把开发和测试都拉进来一起审视这些接口价值比单纯升一个版本要大得多。我在处理完 CVE-2024-38819 之后最大的感受是安全修复不能只盯着依赖版本。有时候漏洞的根子不在框架而在我们自己写代码的方式。一个RouterFunction路由此刻被堵住了如果业务代码里还有一堆手拼路径的下载接口那迟早还要再来一次类似的排查。趁着这次升级不妨把项目的文件处理逻辑整体梳理一遍一劳永逸。
说实话这个洞我一开始没太当回事直到某次安全扫描把报告甩到群里标题写着“CVE-2024-38819 目录遍历”我才愣了一下。毕竟一直在 Spring Boot 项目里直觉第一反应就是官方都修复了升个版本不就完了结果一查才意识到这里面的“特定条件下”几个字才是整个排查过程最折腾人的地方。它不是那种“只要用了 Spring Boot 就中招”的漏洞而是跟你项目的路由写法直接相关。如果你现在也正在处理这个编号或者安全团队让赶紧修我建议把这篇看完能少走不少弯路。1. CVE-2024-38819 到底打在了哪里函数式路由的路径校验盲区1.1 传统控制器与函数式路由在路径解析上的差异很多项目现在用的是传统写法RestControllerRequestMapping(/xxx)。这种写法下Spring MVC 的资源处理链路是经过ResourceHttpRequestHandler的它内部有一套比较完整的资源解析器链PathResourceResolver只是其中一环前后还有别的校验所以在传统接口里../这种目录穿越请求基本会被拦得比较死。CVE-2024-38819 影响的是另外一套东西——WebMvc.fn和WebFlux.fn也就是函数式路由。这套风格用RouterFunction来定义接口写起来确实简洁比如Bean public RouterFunctionServerResponse route() { return RouterFunctions.route() .GET(/api/hello, request - ServerResponse.ok().body(hello)) .build(); }静态资源也能用函数式方式暴露Bean public RouterFunctionServerResponse staticResources() { return RouterFunctions .resources(/static/**, new ClassPathResource(static/)); }问题就出在这个resources(/static/**, ...)这类路径映射上。函数式路由在把请求转发给资源处理器时它内部对路径的解析、解码、校验顺序跟传统ResourceHttpRequestHandler并不完全一致。简单说它在某些环节里没有对“路径片段是否为..”做强制收紧这就给目录遍历留下了口子。1.2 触发条件拆解RouterFunction 与静态资源映射缺一不可这个漏洞不是说你引入了函数式路由就完蛋它还需要满足两个条件接口是通过RouterFunction暴露的并且处理的是资源请求比如静态文件、下载文件。请求路径可以被攻击者控制并且包含了 URL 编码后的../片段。举个例子假设项目里用RouterFunctions.resources(/static/**, location)暴露了静态资源攻击者请求/static/%2e%2e/%2e%2e/application.properties这里的%2e%2e是..的 URL 编码形式%2f是/的编码形式。在老版本代码里函数式路由内部把请求路径解码后直接拿去定位资源却没有像传统资源处理器那样在每一层解析里都检查..片段于是文件读取就跳出了静态资源目录跑到了项目目录甚至系统目录。为什么很多扫描器只在特定条件下报这个 CVE因为它不是通用的RequestMapping注解接口而是函数式路由这一条链路上的问题。如果你项目里全是传统控制器没有RouterFunctions那这个漏洞大概率扫不到你头上。但问题是很多工程是“新旧混用”的老模块用注解新模块用了函数式路由这类项目恰恰最容易中招。路由方式是否受 CVE-2024-38819 影响传统RequestMapping/RestController不受该漏洞直接影响RouterFunction暴露业务接口不受直接影响RouterFunction暴露资源文件/静态文件受影响传统 resource handler 配置不受该漏洞直接影响1.3 官方版本范围与修复版本怎么对照官方公告里给出的修复版本大致是这样的Spring Framework 5.3.x 线需要升到 5.3.40 以上6.1.x 线需要升到 6.1.14 以上6.2.x 线上使用包含修复的正式发布版本。6.0.x 已经到了社区维护停止状态官方基本只让你往上升不推荐继续停留在 6.0 系列。在 Spring Boot 项目里情况要稍微绕一下。Boot 自己不会单独发一个“修复版本”它是通过内置的 Spring Framework 依赖版本来带修复的。所以你需要关注的不是“Boot 是否出了 CVE 公告”而是“Boot 默认管理的 Framework 版本是否已经落在修复范围内”。我当时用的是 Boot 3.2 系默认对应的 Framework 是 6.1.x所以修复的路径就是要么把 Boot 升到已经内置 Framework 6.1.14 的新补丁版要么单独把spring-framework.version属性覆盖到修复版本。这里我强烈建议优先升级 Boot而不是手动改 Framework 版本。2. 自测清单三分钟判断项目有没有踩中这个洞2.1 用 dependency:tree 查看真实依赖别凭记忆判断“我项目里应该没用到函数式路由”先把依赖树拉出来看一眼。Maven 项目直接执行mvn dependency:tree -Dincludesorg.springframework:*重点关注spring-webmvc、spring-webflux、spring-web这几个模块的版本号。如果是 Gradle 项目./gradlew dependencyInsight --dependency org.springframework:spring-web这里要特别提醒一句有些项目里你根本不知道自己间接引入了旧版 Spring。比如某个内部公共库传递依赖了旧的spring-webmvc而你的主 pom 用的是 Boot 管理Boot 的 BOM 并不能把别人传递进来的依赖强制覆盖掉除非你把版本在 dependencyManagement 里显式锁住。所以扫描器报“CVE-2024-38819 未修复”时第一件事不是改版本而是先定位是哪个模块引入了旧版本。2.2 代码层面检查有没有 RouterFunction依赖版本符合修复范围不代表万事大吉你还得看代码到底有没有用函数式路由。最快的方法rg -n RouterFunctions|RouterFunction|HandlerFunction src/main/java或者直接在 IDE 里全局搜RouterFunctions。如果没有任何结果说明项目大概率没有使用 WebMvc.fn / WebFlux.fn 的资源处理逻辑那这个漏洞跟你的运行时代码基本无关更多是依赖版本需要跟进。但这里有一个很容易漏的点有些接口是用函数式路由写的但暴露的不是资源文件而是 JSON 接口。这类也不会受到目录遍历影响。受影响的核心是那个router.resources(...)或者通过RouterFunction去转发Resource的地方。如果你的函数式路由只返回数据那不需要太担心。另外如果项目里同时存在老式的WebMvcConfigurer.addResourceHandlers配置这个漏洞不直接覆盖那种写法那套链路依然走ResourceHttpRequestHandler的完整校验。真正要排查的是RouterFunctions场景下的资源处理。2.3 在本地环境构造验证请求既然要确认有没有这个洞最直接的办法就是在本地测试环境打一个验证请求。这里强调一下别拿公网实例试更别拿生产环境试所有验证都在自己可控的环境里做。我当时是在本地调试端口上跑的并且读取的目标文件是项目自己的配置文件。假设项目里暴露了/static/**的静态资源路由本地端口是 8080验证命令可以这样curl -i --path-as-is http://127.0.0.1:8080/static/%2e%2e/%2e%2e/application.properties这里有个关键参数是--path-as-is。不加这个参数的话curl 会在发出请求前自己把/static/../application.properties规范化路径直接变成/application.properties那测的就不对味了。有了--path-as-iscurl 会原样发送这段带编码的路径让服务端去解析。如果返回 200 且 body 里出现了application.properties的内容说明确实存在问题。如果返回 404 / 400说明当前版本或者当前配置已经挡住了这类请求。除了单次编码%2e%2e%2f你还可以试双重编码curl -i --path-as-is http://127.0.0.1:8080/static/%252e%252e%252f%252e%252e%252fapplication.properties有些早期的目录遍历漏洞在单重编码被修复后双重编码还能绕过。Spring 这个 CVE 在修复版本里做了比较彻底的收紧两条请求都应该被拦下来才对。请求路径编码含义修复前预期修复后预期/static/../application.properties未编码可能被容器规范化404/static/%2e%2e/%2e%2e/application.properties单次 URL 编码可能命中漏洞404/400/static/%252e%252e%252f%252e%252e%252fapplication.properties双重 URL 编码少数情况能命中404/4003. 修复落地升级版本的正确姿势与临时缓解措施3.1 升级 Boot 而不是单独换 Framework我在处理这个 CVE 的时候一开始的方案是“只升级 spring-webmvc”后来发现这是个非常不推荐的做法。Spring Boot 的依赖管理是成体系的Boot parent 的dependencyManagement里锁定了所有 Spring 模块的版本。如果你手动把某个模块的版本改了轻则依赖树里出现多个不一致的 Spring jar 包重则启动时直接报方法不兼容的问题。正确做法是直接升级 Spring Boot 版本。比如我那个项目从 Boot 3.2.x 拉到了 3.3.x 的最新补丁版Boot 内置的 Framework 版本自然就超过了 6.1.14。具体升级时把父 pom 里的版本改成自己依赖管理最新可用版parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.3.6/version relativePath/ /parent这里的版本号只是个示例实际升级前先去官方仓库看可用的最新补丁版。升级后不要只盯着spring-webmvc有没有变spring-core、spring-context、spring-web都要一起对齐。最稳妥的操作是执行一次干净构建mvn clean verify然后在启动日志里看 banner 下方的 Spring 版本号确认已经是修复后的版本。3.2 如果暂时升不了级临时过滤器怎么加有些项目确实有特殊情况比如依赖的公共库还没做兼容或者升级窗口不在当前迭代这种情况你至少要做一层临时缓解。一个比较通用的方式是在 Servlet 链路上加一个前置过滤器对请求路径里的目录遍历特征做拦截。我当时根据自己的项目现状写了一个过滤器思路是这样的拿到原始 URI做一次 URL 解码然后检查解码结果里是否包含../、..\\这类特征。如果有直接返回 400。Component Order(Ordered.HIGHEST_PRECEDENCE) public class PathTraversalProtectionFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest httpRequest (HttpServletRequest) request; String requestUri httpRequest.getRequestURI(); String decoded URLDecoder.decode(requestUri, StandardCharsets.UTF_8); if (decoded.contains(../) || decoded.contains(..\\) || decoded.contains(/./) || decoded.contains(%2e) || decoded.contains(%252e)) { ((HttpServletResponse) response).sendError(HttpServletResponse.SC_BAD_REQUEST); return; } chain.doFilter(request, response); } }这里有几个细节要注意第一为什么用getRequestURI()而不直接用getPathInfo()因为在不同容器上路径信息的分法不一样直接拿 URI 最稳妥。第二URLDecoder.decode会把转成空格不过这里只是判断路径特征不太受影响。第三双重编码的问题要小心。%252e%252e%252f解码一次后是%2e%2e%2f如果你只检查原始 URI 里的../是检查不到的所以我还额外判断了解码结果里是否还存在%2e这种残留特征。实际生产环境的复杂度还会更高但这个过滤器作为“临时挡板”是够用的。3.3 用属性覆盖 Framework 版本的临时方案如果是 Spring Boot 项目又没法立刻升级 Boot 版本还可以利用 Boot 的依赖管理属性做临时修复。Spring Boot parent pom 里暴露了spring-framework.version这个属性允许你单独控制 Spring Framework 的版本号properties spring-framework.version6.1.14/spring-framework.version /properties这个方案比手动改某个 jar 包版本要靠谱一些因为它至少没有绕过 Boot 的 BOM 管理只是覆盖了整个 Framework 家族。但不要长期依赖这个方式。Boot 版本和 Framework 版本之间有潜在兼容性问题比如 Boot 3.2 官方配套的是 6.1.x你硬把它改成 6.1.14 问题不大但改成 6.2.x 就不一定了。所以我的建议是属性覆盖只适合救急升级计划还是要排上日程。4. 升级后复测与自动化回归别让漏洞换个姿势回来4.1 同一条 curl 的前后对比版本升级完成后我最关心的就是之前那条能返回文件内容的请求现在会变成什么状态。操作步骤很简单重新构建项目并启动服务。再次执行前面提到的 curl 命令。看响应状态码和响应体。修复后/static/%2e%2e/%2e%2e/application.properties应该返回 404 或者被框架直接拒绝响应体里不再出现文件内容。我在实际验证时还顺手试了下面这几种组合curl -i --path-as-is http://127.0.0.1:8080/static/..%2f..%2fapplication.properties curl -i --path-as-is http://127.0.0.1:8080/static/%2e%2e%2f%2e%2e%2fapplication.properties curl -i --path-as-is http://127.0.0.1:8080/static/..%5c..%5capplication.properties全部被拦截才算放心。这里有个经验之谈修复类 CVE 的验证不能只看一条 payload 就收工。目录遍历类的 payload 变体非常多尤其要注意反斜杠\的编码形式也就是%5c。虽然 Linux 下反斜杠不是路径分隔符但 Windows 容器上..\\可能被当成路径穿越。4.2 把漏洞回归写进自动化测试很多项目的安全修复都是“改了跑通了上线了再没人管”。这种做法最大的隐患是下次有某个同事重新拉了旧分支或者公共依赖被误降版本漏洞可能悄无声息地又回来了。所以我建议把这次验证固化到自动化测试里。如果你的项目用的是 Spring Boot 的MockMvc可以写一个简单的回归用例直接在测试里断言“目录穿越请求必须被拒绝”Test void pathTraversalShouldBeRejected() throws Exception { mockMvc.perform(get(/static/%2e%2e/%2e%2e/application.properties)) .andExpect(status().isNotFound()); }有一点要提前说明MockMvc在某些情况下会把请求路径做一定程度的规范化不一定能百分百复现生产环境上真实的绕过场景所以这个测试更适合作为“回归基线”而不是“唯一验证标准”。真正上线前最好还是在独立的测试环境里用真实 HTTP 请求做一次端到端验证。4.3 升级后扫描平台可能出现的误报与漏报安全扫描平台给出的结果不一定完全反映实际运行状态。有些扫描器是基于版本号判断的只要它检测到旧版本就会报“未修复”哪怕你的代码里根本没用函数式路由也会被标记。这类误报处理起来很简单在复测时把扫描结果和实际情况一起附上说明项目并未使用受影响功能然后升级版本后重新扫描。反过来也要提防漏报。有些扫描器只发一两个固定 payload如果你的接口用的是双重编码或者大小写混写扫描器可能测不出来。所以我在复测时会手动补测几个变体宁可多试几条也不要让问题藏在扫描盲区里。5. 目录遍历类漏洞的通用防御习惯这次修的不仅是 Spring5.1 所有“下载文件”功能都可能出现同类问题CVE-2024-38819 是 Spring 的漏洞但目录遍历这一类问题绝不仅是框架的问题。我见过太多业务代码里直接做文件下载的接口写法基本就是String filePath uploadDir File.separator fileName; return ResponseEntity.ok(Files.newInputStream(Paths.get(filePath)));这代码如果fileName是用户传的那它的风险不比这次 Spring 的漏洞小。攻击者把fileName传成../../../etc/passwd文件流照样能打开。所以借着修这个 CVE 的机会我建议把所有涉及文件读取的接口都盘一遍。5.2 路径校验的正确姿势与常见反模式一个常见的反模式是“黑名单过滤”遇到../就拒绝。这种校验很容易被编码绕过比如%2e%2e%2f、双重编码、Unicode 半角/全角字符等。更稳妥的方式是白名单思维加路径规范化校验。具体来说把用户输入先解析成Path然后做normalize()再判断最终路径是否仍然位于允许的目录内public static Path safeResolve(Path baseDir, String userInput) { Path target baseDir.resolve(userInput).normalize(); if (!target.startsWith(baseDir)) { throw new IllegalArgumentException(非法路径); } return target; }normalize()会把..和.片段消除掉。消除之后再判断startsWith(baseDir)如果目标目录跑到了白名单目录外面直接拒绝。这是目前比较推荐的校验方式。另外文件下载接口最好连“路径”都不要让用户传。前端传文件 ID 或者业务主键后端通过 ID 查表得到真实文件名这样用户完全没有机会注入路径。我在项目里推进的规范就是能查表就不拼路径能传 ID 就不传文件名。5.3 给新代码加一条安全检查清单我在团队内部定了一个简单的自查清单每次新增文件上传下载、静态资源暴露相关接口时都过一遍检查项推荐做法用户输入是否直接参与文件路径拼接改为传 ID/业务键由后端映射真实路径是否允许文件名里带路径分隔符不允许统一用PathAPI 处理是否对最终路径做了normalize()必须做且校验startsWith(baseDir)是否暴露了超出预期的静态资源目录只暴露独立目录不使用file:///根路径是否依赖黑名单过滤../不依赖改用白名单 路径规范化这些习惯说起来简单但真正落地的时候项目里总会冒出一些历史代码不遵守。借着修复一个 CVE 的契机把开发和测试都拉进来一起审视这些接口价值比单纯升一个版本要大得多。我在处理完 CVE-2024-38819 之后最大的感受是安全修复不能只盯着依赖版本。有时候漏洞的根子不在框架而在我们自己写代码的方式。一个RouterFunction路由此刻被堵住了如果业务代码里还有一堆手拼路径的下载接口那迟早还要再来一次类似的排查。趁着这次升级不妨把项目的文件处理逻辑整体梳理一遍一劳永逸。
