仔细研究mvcRequestMatcher Spring的漏洞
毋庸置疑,这是个很好的机会。悬浮在空中的各种元素的三层结构。他说:"我的意思是说,我可以在这里工作,但我不能在这里工作,因为我不能在这里工作,因为我不能在这里工作。在这里,我想说的是,我们要做的是,在我们的生活中,我们要做的是,在我们的生活中,我们要做的是,在我们的生活中,我们要做的是。在这里,我想说的是,我们的生命力是有限的。
仔细研究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的案例,而不是一个错误或漏洞。

在博客上深入了解我们最新的安全编码见解。
我们广泛的资源库旨在增强人类对安全编码技术提升的方法。
获取关于开发者驱动的安全的最新研究
我们广泛的资源库充满了有用的资源,从白皮书到网络研讨会,让你开始使用开发者驱动的安全编码。现在就去探索它。
仔细研究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的案例,而不是一个错误或漏洞。