Spring WebFlux 授权绕过：CVE-2024-38821 详解

Spring 于 2024 年 10 月 25 日宣布了 CVE-2024-38821，这是一个严重漏洞，允许攻击者在某些情况下访问受限资源。该漏洞特别影响 Spring WebFlux 的静态资源服务。要影响应用程序，必须满足以下所有条件：它必须是 WebFlux 应用程序。

Spring 于 2024 年 10 月 25 日宣布了 CVE-2024-38821，这是一个严重漏洞，允许攻击者在某些情况下访问受限资源。

该漏洞特别影响 Spring WebFlux 的静态资源服务。要影响应用程序， 必须满足以下所有条件：

• 它必须是一个 WebFlux 应用程序。

• 它必须使用 Spring 的静态资源支持。

• 必须对静态资源支持应用非permitAll授权规则。

在本文中，我们将深入研究此漏洞的细节，并分析它为何只影响静态资源。

PoC 可在以下位置找到：https://github.com/mouadk/cve-2024-38821/tree/main

漏洞

在本节中，我们将深入探讨该漏洞的细节，包括一些背景信息。

如果你不喜欢阅读，这里有一个演示漏洞流程的图。

WebFilterChainProxy 类

Spring Security 使用安全过滤器执行其大部分核心逻辑。通常，当我们定义多个安全过滤器时，为了方便委托，过滤器链位于顶部，并负责将响应转发给下一个过滤器。

DefaultWebFilterChain 实际上是 WebFilterChain 的默认实现。WebFilterChainProxy 是一个用于委托给 SecurityWebFilterChain 实例列表的过滤器。

网页过滤链代理

我们可以在应用程序中配置多个安全过滤器。只有当所有过滤器都接受请求时，请求才能继续在应用程序中传输。

调度处理程序类

DispatcherHandler类似于DispatcherServletSpring MVC，负责处理 http 请求。在初始化阶段，它会根据收到的请求发现需要委托任务的特殊 bean。处理逻辑实际上是在下面显示的 DispatcherHandler 的 handle 方法中实现的。

这基本上是这样的：

• 对于每个尝试获取适当处理程序的映射，此处的语义以首先找到的处理程序为准。如果找不到处理程序，则会引发异常。

• 接下来，invoke handler 将尝试解析支持当前 handler 的 HandlerAdapter。如果未找到，则会向下游发送错误。

给定一个 http 请求（封装在 ServerWebExchange 中），getHandler 实际上负责解析该请求的处理程序。

抽象处理程序映射

当请求到达时， DispatcherHandler 只有安全过滤器通过后才会调用。如果安全过滤器链允许或拒绝请求失败，则会 DispatcherHandler 识别适当的处理程序（通过顺序评估潜在匹配项并选择第一个成功的处理程序）。

攻击者可以利用精心设计的 URL 路径绕过安全过滤器，从而避免对受保护资源进行检查。例如，如果您想要保护 /index.html，攻击者可以操纵 URL 以 //index.html。由于安全过滤器执行严格的路径匹配，因此它不适用于这种情况，可能会导致资源不受保护。如果绕过所有安全过滤器，则可能导致不受限制的访问。

一旦通过安全过滤器，特定处理程序就会处理请求。Spring 中默认添加了 一个特定处理程序ResourceWebHandler （  ），用于从 中定义的特定位置提供静态资源（如图像、HTML 和 YAML 文件） ，包括：HttpRequestHandler、ResourceHandlerRegistry

• public/

• static/

• resources/

• META-INF/resources/

例如，使用路径 ..//index.html，请求的路径将使用 进行解析 exchange.getRequiredAttribute(HandlerMapping.PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE)，结果为 index.html。因此，攻击者可以利用此机制。

ResourceWebHandler

为何非静态资源不受影响

非静态资源的行为有所不同。这些路由的处理程序使用谓词来验证请求，即使绕过所有安全过滤器也是如此。例如， PathPatternPredicate 严格匹配路径并拒绝未通过此匹配的请求，导致 HTTP 400 NOT FOUND，而不是授予意外访问权限。

请求谓词

攻击流程

攻击者通过应用程序的路径如下： DispatcherHandler -> SimpleHandlerAdapter -> ResourceWebHandler -> PathResourceResolver -> Resource -> Attacker Access

该漏洞由[email protected]负责任地报告 。

演示

PoC 可在以下位置找到：https://github.com/mouadk/cve-2024-38821/tree/main

让我们配置以下设置来保护对特定路径的访问，包括 /secure/hello、 /index.html和 /application.yaml：

接下来我们配置以下路线：

我们可以确认此配置对于非恶意请求能够按预期工作。

然而，只需进行轻微修改（例如添加反斜杠（/），攻击者就可以绕过过滤器并访问静态资源。

相反， /secure/hello使用此修改来访问动态资源（如）会导致“未找到”错误，如前所述。

修复

https://github.com/spring-projects/spring-security/commit/4ce7cde15599c0447163fd46bac616e03318bf5b#diff-dd76f194f47c99da94b2808df1bf614d087a8ebbbd1fca1fea9a096ea9bbd176R11

该解决方案涉及增强查询验证。具体来说，在安全链中引入了防火墙，以在请求到达过滤器链之前对其进行验证。您可以在此处（上方）查看提交：  GitHub Commit-https://github.com/spring-projects/spring-security/commit/4ce7cde15599c0447163fd46bac616e03318bf5b?ref=deep-kondah.com#diff-dd76f194f47c99da94b2808df1bf614d087a8ebbbd1fca1fea9a096ea9bbd176R11 ServerWebExchangeFirewall 。此更新引入了 （特别是 StrictServerWebExchangeFirewall）具有附加验证方法的版本 。

强烈建议升级您的 Spring 依赖项，并采用“默认拒绝”方法。此外，请考虑使用声明式安全性，这对攻击者来说更具挑战性，因为他们经常操纵安全过滤器链。

如果我们重试之前的请求，我们会收到“错误请求”错误：

这也表明，虽然 RASP 很有用，但它可能无法发现这一漏洞。至于 ADR，其有效性可能会有所不同。

要强硬，要严格（对于攻击者:)）

原文始发于微信公众号（Ots安全）：Spring WebFlux 授权绕过：CVE-2024-38821 详解