仔细研究mvcRequestMatcher Spring的漏洞

2023年3月20日，Spring Security Advisories发表了一篇博文，提到了一个内部发现的漏洞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和Spr ing MVC之间的模式匹配发生了不匹配"，从而产生了这个漏洞。

从本质上讲，由于双通配符前面没有分隔符，路径不匹配传入的请求，因为所有传入的请求都以斜线为前缀。这意味着访问控制规则没有被应用，允许任何未经认证的用户访问资源。

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

最突出和重要的变化是增加了第315行，它解决了绕过授权和认证规则的问题。它确保任何提交的路径模式，都以正斜杠（/）为前缀。 

404 未找到匹配项

当向/bankaccounts/view 发送网络请求时，匹配方法将解析并比较安全过滤器中定义的模式与请求的路径。解析器将把给定的模式变成一棵树的路径元素。

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

那么，用**作为模式时，哪里出了问题？ 

虽然有很多路径元素类型，但这里最有趣的是WildcardPathElement和WildcardTheRestPathElement，它们分别用字符串表示：*和/**。 

WildcardPathElement匹配单个路径段中的零个或多个字符，而WildcardTheRestPathElement匹配零个或多个单独的路径段（包括分隔符）。

后者给了我们一个线索，说明在提交**作为模式时出了什么问题。在解析过程中，它寻找模式，但**并没有以预期的正斜杠开始。所以它没有成为WildcardTheRestPathElement，而是变成了两个连续的WildcardPathElements。

接下来，解析后的模式被用来与请求的URL匹配。路径应以正斜线开始，但通配符不与分隔符匹配。

这意味着返回的不是一个RequestMatchResult，而是一个null。因此，放在这个匹配器上的访问控制规则不会被应用到所请求的URL上。

Spring通过预加斜线解决了这个问题。换句话说，任何**模式都会变成/**，这意味着它可以被解析为WildcardTheRestPathElement，并且会返回一个RequestMatchResult，因为该模式现在与请求的URL相匹配。

漏洞还是API滥用？

这是否应该被认为是一个漏洞是值得商榷的，因为该代码是按预期工作的。问题基本上在于Spring文档中没有明确提到路径应该以分隔符开始。因此，这可以被认为是一个滥用API的案例，而不是一个错误或漏洞。