深入剖析 mvcRequestMatcher Spring 漏洞

2023 年 3 月 20 日，Spring 安全公告发布了一篇 博文，提及了一个内部发现的漏洞，CVE-2023-20860。除指出这是一个涉及使用 mvcMatchers 的访问控制问题外，未披露任何详细信息。Spring 开发人员已修复该问题，并建议进行版本更新。

想亲身体验一下吗？点击此处尝试任务。

由于安全是 Secure Code Warrior 的核心关注点，我们决定深入研究此 mvcRequestMatchers 漏洞，找出问题的根源所在。

Spring 提供了 RequestMatcher 接口来确定请求是否与路径模式匹配。请查看下方的代码片段，其中使用了 mvcMatchers 辅助方法来注册端点及其身份验证和授权要求。例如，我们可以看到只有拥有 ADMIN 角色的用户才能访问 /logs/audit 端点。

MvcMisMatchers？

在 Spring 中， ** 是一种用于匹配 URL 中任意数量目录和子目录的模式。例如，/bankaccount/** 将匹配所有以 /bankaccount/ 开头的 URL，包括诸如 /bankaccount/dashboard/settings 之类的子目录。

星号 * 模式用于匹配任意 URL，且仅限一级子目录。例如，/bankaccount/* 将匹配 bankaccount/dashboard。

当使用 * 配置匹配器时，Spring 指出发生了 “Spring Security 与 Spring MVC 之间的模式匹配不一致”，从而导致了该漏洞。

本质上，由于双通配符前面缺少分隔符，该路径无法匹配传入的请求，因为所有传入请求的前面都预置了斜杠。这意味着访问控制规则未被应用，从而允许任何未经身份验证的用户访问这些资源。

让我们来看看修复该问题的 提交记录。

最显著且最重要的更改是增加了第 315 行，它修复了授权和身份验证规则被绕过的问题。它确保提交的任何路径模式前面都会预置一个正斜杠 (/)。

404 未找到匹配项

当向 /bankaccounts/view 发送 Web 请求时，match 方法将解析并比较安全过滤器中定义的模式与请求路径。解析器会将给定的模式转换为路径元素树。

解析器将第一个字符读取为 SeparatorPathElement。然后它继续读取字符串字符，直到遇到下一个分隔符，从而创建一个新的 LiteralPathElement。

那么，当使用 ** 作为模式时，问题出在哪里呢？

虽然路径元素类型有很多，但其中最值得关注的是 WildcardPathElement 和 WildcardTheRestPathElement，它们对应的字符串表示形式分别为 * 和 /**。 

一个 WildcardPathElement 可以匹配单个路径段内的零个或多个字符，而 WildcardTheRestPathElement 则可以独立匹配零个或多个路径段（包括分隔符）。

后者为我们揭示了提交 ** 作为模式时出错的原因。在解析过程中，系统会查找模式，但 ** 并不以预期的正斜杠开头。因此，它没有被解析为 WildcardTheRestPathElement，而是变成了两个连续的 WildcardPathElements。

接下来，解析后的模式将用于匹配请求的 URL。路径通常应以正斜杠开头，但通配符不会匹配分隔符。

这意味着返回的不是 RequestMatchResult，而是 null。因此，应用于此匹配器的访问控制规则将不会在请求的 URL 上生效。

Spring 通过在开头添加斜杠修复了此问题。换句话说，任何 ** 模式都会变为 /**，从而可以被解析为 WildcardTheRestPathElement，并返回一个 RequestMatchResult，因为该模式现在可以匹配请求的 URL 了。

是漏洞还是 API 误用？

这是否应被视为漏洞尚存争议，因为代码本身按预期运行。问题的核心在于 Spring 文档 未明确指出路径应以分隔符开头。因此，这更倾向于 API 误用，而非程序错误或漏洞。