仔细研究mvcRequestMatcher Spring的漏洞
2023年3月20日,Spring Security Advisories发表了一篇博文,提到了一个内部发现的漏洞CVE-2023-20860。没有披露详细的信息,只是说这是一个关于使用mvcMatchers的访问控制问题。Spring的开发人员已经修复了这个问题,并建议进行版本更新。
你想亲身体验一下吗?在这里尝试一下任务。
由于安全是我们的主要关注点 Secure Code Warrior我们决定深入研究这个mvcRequestMatchers漏洞,找出核心问题所在。
Spring提供了RequestMatcher接口来确定一个请求是否符合路径模式。请看下面的代码片段,其中mvcMatchers辅助方法被用来注册端点以及它们的认证和授权要求。例如,我们可以看到,只有ADMIN角色的用户可以访问/logs/audit 端点。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad219_64400b95059a87dfdb10e86b_code-block-1.png)
MvcMisMatchers?
在Spring中, **是一种模式,可以匹配URL中任何数量的目录和子目录。例如,/bankaccount/**将匹配所有以/bankaccount/开头的URL,包括子目录,如/bankaccount/dashboard/settings。
*模式是一个匹配任何URL的模式,并且正好有一级子目录。例如,/bankaccount/* 将匹配bankaccount/dashboard。
当用*配置匹配器时,Spring表示"Spring Security和Spr ing MVC之间的模式匹配发生了不匹配",从而产生了这个漏洞。
从本质上讲,由于双通配符前面没有分隔符,路径不匹配传入的请求,因为所有传入的请求都以斜线为前缀。这意味着访问控制规则没有被应用,允许任何未经认证的用户访问资源。
让我们看看修复该问题的提交。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad22d_643fc7d3e1ca1a5117329c74_f24b5spYh-5YSUWbTgjOR873kwe9Zokg7HcNdv-NJasWTBytgNbrt0AZGaNNBOCKUuasibRVCyiWo-GMGnnvxSo6DrN9oKdTAeEPVG5xNrPi-P-4CwJMcjvWHubQyS5T3uoFvVRJAayWqD2VxILEBQM.png)
最突出和重要的变化是增加了第315行,它解决了绕过授权和认证规则的问题。它确保任何提交的路径模式,都以正斜杠(/)为前缀。
404 未找到匹配项
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad21c_64400baee212a629597bdc40_code-block-2.png)
当向/bankaccounts/view 发送网络请求时,匹配方法将解析并比较安全过滤器中定义的模式与请求的路径。解析器将把给定的模式变成一棵树的路径元素。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad214_643fc8c71437d0b2cc8c6914_%253Abankaccounts%253Aview.png)
解析器读取第一个字符作为SeparatorPathElement。然后它继续读取字符串字符,直到下一个分隔符,创建一个新的LiteralPathElement。
那么,用**作为模式时,哪里出了问题?
虽然有很多路径元素类型,但这里最有趣的是WildcardPathElement和WildcardTheRestPathElement,它们分别用字符串表示:*和/**。
WildcardPathElement匹配单个路径段中的零个或多个字符,而WildcardTheRestPathElement匹配零个或多个单独的路径段(包括分隔符)。
后者给了我们一个线索,说明在提交**作为模式时出了什么问题。在解析过程中,它寻找模式,但**并没有以预期的正斜杠开始。所以它没有成为WildcardTheRestPathElement,而是变成了两个连续的WildcardPathElements。
接下来,解析后的模式被用来与请求的URL匹配。路径应以正斜线开始,但通配符不与分隔符匹配。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad211_644259043d142e4380b218d6_code-block-3.png)
这意味着返回的不是一个RequestMatchResult,而是一个null。因此,放在这个匹配器上的访问控制规则不会被应用到所请求的URL上。
Spring通过预加斜线解决了这个问题。换句话说,任何**模式都会变成/**,这意味着它可以被解析为WildcardTheRestPathElement,并且会返回一个RequestMatchResult,因为该模式现在与请求的URL相匹配。
漏洞还是API滥用?
这是否应该被认为是一个漏洞是值得商榷的,因为该代码是按预期工作的。问题基本上在于Spring文档中没有明确提到路径应该以分隔符开始。因此,这可以被认为是一个滥用API的案例,而不是一个错误或漏洞。
![黄色几何抽象背景上的骷髅头图标](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/643fc914018b33e1cad58645_Spring-vulnerability-blog-image.webp)
![黄色几何抽象背景上的骷髅头图标](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/643fc914018b33e1cad58645_Spring-vulnerability-blog-image.webp)
2023年3月20日,Spring Security Advisories发表了一篇博文,提到了一个内部发现的漏洞CVE-2023-20860。没有披露详细的信息,只是说这是一个关于使用`mvcMatchers'的访问控制问题。Spring开发者已经修复了这个问题,并建议进行版本更新。由于安全是我们在Secure Code Warrior ,我们决定深入研究这个mvcRequestMatchers漏洞,找出核心问题所在。
![](https://cdn.prod.website-files.com/5fec9210c1841a81c9c6ce7d/66d0b4fa43284a440c24b591_learn-more.avif)
Secure Code Warrior 我们在这里为您的组织提供服务,帮助您在整个软件开发生命周期中确保代码安全,并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人,我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示Brysen是Secure Code Warrior 的一名软件开发人员,专注于编写安全代码。
![黄色几何抽象背景上的骷髅头图标](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/643fc914018b33e1cad58645_Spring-vulnerability-blog-image.webp)
![黄色几何抽象背景上的骷髅头图标](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/643fc914018b33e1cad58645_Spring-vulnerability-blog-image.webp)
2023年3月20日,Spring Security Advisories发表了一篇博文,提到了一个内部发现的漏洞CVE-2023-20860。没有披露详细的信息,只是说这是一个关于使用mvcMatchers的访问控制问题。Spring的开发人员已经修复了这个问题,并建议进行版本更新。
你想亲身体验一下吗?在这里尝试一下任务。
由于安全是我们的主要关注点 Secure Code Warrior我们决定深入研究这个mvcRequestMatchers漏洞,找出核心问题所在。
Spring提供了RequestMatcher接口来确定一个请求是否符合路径模式。请看下面的代码片段,其中mvcMatchers辅助方法被用来注册端点以及它们的认证和授权要求。例如,我们可以看到,只有ADMIN角色的用户可以访问/logs/audit 端点。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad219_64400b95059a87dfdb10e86b_code-block-1.png)
MvcMisMatchers?
在Spring中, **是一种模式,可以匹配URL中任何数量的目录和子目录。例如,/bankaccount/**将匹配所有以/bankaccount/开头的URL,包括子目录,如/bankaccount/dashboard/settings。
*模式是一个匹配任何URL的模式,并且正好有一级子目录。例如,/bankaccount/* 将匹配bankaccount/dashboard。
当用*配置匹配器时,Spring表示"Spring Security和Spr ing MVC之间的模式匹配发生了不匹配",从而产生了这个漏洞。
从本质上讲,由于双通配符前面没有分隔符,路径不匹配传入的请求,因为所有传入的请求都以斜线为前缀。这意味着访问控制规则没有被应用,允许任何未经认证的用户访问资源。
让我们看看修复该问题的提交。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad22d_643fc7d3e1ca1a5117329c74_f24b5spYh-5YSUWbTgjOR873kwe9Zokg7HcNdv-NJasWTBytgNbrt0AZGaNNBOCKUuasibRVCyiWo-GMGnnvxSo6DrN9oKdTAeEPVG5xNrPi-P-4CwJMcjvWHubQyS5T3uoFvVRJAayWqD2VxILEBQM.png)
最突出和重要的变化是增加了第315行,它解决了绕过授权和认证规则的问题。它确保任何提交的路径模式,都以正斜杠(/)为前缀。
404 未找到匹配项
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad21c_64400baee212a629597bdc40_code-block-2.png)
当向/bankaccounts/view 发送网络请求时,匹配方法将解析并比较安全过滤器中定义的模式与请求的路径。解析器将把给定的模式变成一棵树的路径元素。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad214_643fc8c71437d0b2cc8c6914_%253Abankaccounts%253Aview.png)
解析器读取第一个字符作为SeparatorPathElement。然后它继续读取字符串字符,直到下一个分隔符,创建一个新的LiteralPathElement。
那么,用**作为模式时,哪里出了问题?
虽然有很多路径元素类型,但这里最有趣的是WildcardPathElement和WildcardTheRestPathElement,它们分别用字符串表示:*和/**。
WildcardPathElement匹配单个路径段中的零个或多个字符,而WildcardTheRestPathElement匹配零个或多个单独的路径段(包括分隔符)。
后者给了我们一个线索,说明在提交**作为模式时出了什么问题。在解析过程中,它寻找模式,但**并没有以预期的正斜杠开始。所以它没有成为WildcardTheRestPathElement,而是变成了两个连续的WildcardPathElements。
接下来,解析后的模式被用来与请求的URL匹配。路径应以正斜线开始,但通配符不与分隔符匹配。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad211_644259043d142e4380b218d6_code-block-3.png)
这意味着返回的不是一个RequestMatchResult,而是一个null。因此,放在这个匹配器上的访问控制规则不会被应用到所请求的URL上。
Spring通过预加斜线解决了这个问题。换句话说,任何**模式都会变成/**,这意味着它可以被解析为WildcardTheRestPathElement,并且会返回一个RequestMatchResult,因为该模式现在与请求的URL相匹配。
漏洞还是API滥用?
这是否应该被认为是一个漏洞是值得商榷的,因为该代码是按预期工作的。问题基本上在于Spring文档中没有明确提到路径应该以分隔符开始。因此,这可以被认为是一个滥用API的案例,而不是一个错误或漏洞。
![黄色几何抽象背景上的骷髅头图标](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/643fc914018b33e1cad58645_Spring-vulnerability-blog-image.webp)
2023年3月20日,Spring Security Advisories发表了一篇博文,提到了一个内部发现的漏洞CVE-2023-20860。没有披露详细的信息,只是说这是一个关于使用mvcMatchers的访问控制问题。Spring的开发人员已经修复了这个问题,并建议进行版本更新。
你想亲身体验一下吗?在这里尝试一下任务。
由于安全是我们的主要关注点 Secure Code Warrior我们决定深入研究这个mvcRequestMatchers漏洞,找出核心问题所在。
Spring提供了RequestMatcher接口来确定一个请求是否符合路径模式。请看下面的代码片段,其中mvcMatchers辅助方法被用来注册端点以及它们的认证和授权要求。例如,我们可以看到,只有ADMIN角色的用户可以访问/logs/audit 端点。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad219_64400b95059a87dfdb10e86b_code-block-1.png)
MvcMisMatchers?
在Spring中, **是一种模式,可以匹配URL中任何数量的目录和子目录。例如,/bankaccount/**将匹配所有以/bankaccount/开头的URL,包括子目录,如/bankaccount/dashboard/settings。
*模式是一个匹配任何URL的模式,并且正好有一级子目录。例如,/bankaccount/* 将匹配bankaccount/dashboard。
当用*配置匹配器时,Spring表示"Spring Security和Spr ing MVC之间的模式匹配发生了不匹配",从而产生了这个漏洞。
从本质上讲,由于双通配符前面没有分隔符,路径不匹配传入的请求,因为所有传入的请求都以斜线为前缀。这意味着访问控制规则没有被应用,允许任何未经认证的用户访问资源。
让我们看看修复该问题的提交。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad22d_643fc7d3e1ca1a5117329c74_f24b5spYh-5YSUWbTgjOR873kwe9Zokg7HcNdv-NJasWTBytgNbrt0AZGaNNBOCKUuasibRVCyiWo-GMGnnvxSo6DrN9oKdTAeEPVG5xNrPi-P-4CwJMcjvWHubQyS5T3uoFvVRJAayWqD2VxILEBQM.png)
最突出和重要的变化是增加了第315行,它解决了绕过授权和认证规则的问题。它确保任何提交的路径模式,都以正斜杠(/)为前缀。
404 未找到匹配项
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad21c_64400baee212a629597bdc40_code-block-2.png)
当向/bankaccounts/view 发送网络请求时,匹配方法将解析并比较安全过滤器中定义的模式与请求的路径。解析器将把给定的模式变成一棵树的路径元素。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad214_643fc8c71437d0b2cc8c6914_%253Abankaccounts%253Aview.png)
解析器读取第一个字符作为SeparatorPathElement。然后它继续读取字符串字符,直到下一个分隔符,创建一个新的LiteralPathElement。
那么,用**作为模式时,哪里出了问题?
虽然有很多路径元素类型,但这里最有趣的是WildcardPathElement和WildcardTheRestPathElement,它们分别用字符串表示:*和/**。
WildcardPathElement匹配单个路径段中的零个或多个字符,而WildcardTheRestPathElement匹配零个或多个单独的路径段(包括分隔符)。
后者给了我们一个线索,说明在提交**作为模式时出了什么问题。在解析过程中,它寻找模式,但**并没有以预期的正斜杠开始。所以它没有成为WildcardTheRestPathElement,而是变成了两个连续的WildcardPathElements。
接下来,解析后的模式被用来与请求的URL匹配。路径应以正斜线开始,但通配符不与分隔符匹配。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad211_644259043d142e4380b218d6_code-block-3.png)
这意味着返回的不是一个RequestMatchResult,而是一个null。因此,放在这个匹配器上的访问控制规则不会被应用到所请求的URL上。
Spring通过预加斜线解决了这个问题。换句话说,任何**模式都会变成/**,这意味着它可以被解析为WildcardTheRestPathElement,并且会返回一个RequestMatchResult,因为该模式现在与请求的URL相匹配。
漏洞还是API滥用?
这是否应该被认为是一个漏洞是值得商榷的,因为该代码是按预期工作的。问题基本上在于Spring文档中没有明确提到路径应该以分隔符开始。因此,这可以被认为是一个滥用API的案例,而不是一个错误或漏洞。
2023年3月20日,Spring Security Advisories发表了一篇博文,提到了一个内部发现的漏洞CVE-2023-20860。没有披露详细的信息,只是说这是一个关于使用mvcMatchers的访问控制问题。Spring的开发人员已经修复了这个问题,并建议进行版本更新。
你想亲身体验一下吗?在这里尝试一下任务。
由于安全是我们的主要关注点 Secure Code Warrior我们决定深入研究这个mvcRequestMatchers漏洞,找出核心问题所在。
Spring提供了RequestMatcher接口来确定一个请求是否符合路径模式。请看下面的代码片段,其中mvcMatchers辅助方法被用来注册端点以及它们的认证和授权要求。例如,我们可以看到,只有ADMIN角色的用户可以访问/logs/audit 端点。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad219_64400b95059a87dfdb10e86b_code-block-1.png)
MvcMisMatchers?
在Spring中, **是一种模式,可以匹配URL中任何数量的目录和子目录。例如,/bankaccount/**将匹配所有以/bankaccount/开头的URL,包括子目录,如/bankaccount/dashboard/settings。
*模式是一个匹配任何URL的模式,并且正好有一级子目录。例如,/bankaccount/* 将匹配bankaccount/dashboard。
当用*配置匹配器时,Spring表示"Spring Security和Spr ing MVC之间的模式匹配发生了不匹配",从而产生了这个漏洞。
从本质上讲,由于双通配符前面没有分隔符,路径不匹配传入的请求,因为所有传入的请求都以斜线为前缀。这意味着访问控制规则没有被应用,允许任何未经认证的用户访问资源。
让我们看看修复该问题的提交。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad22d_643fc7d3e1ca1a5117329c74_f24b5spYh-5YSUWbTgjOR873kwe9Zokg7HcNdv-NJasWTBytgNbrt0AZGaNNBOCKUuasibRVCyiWo-GMGnnvxSo6DrN9oKdTAeEPVG5xNrPi-P-4CwJMcjvWHubQyS5T3uoFvVRJAayWqD2VxILEBQM.png)
最突出和重要的变化是增加了第315行,它解决了绕过授权和认证规则的问题。它确保任何提交的路径模式,都以正斜杠(/)为前缀。
404 未找到匹配项
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad21c_64400baee212a629597bdc40_code-block-2.png)
当向/bankaccounts/view 发送网络请求时,匹配方法将解析并比较安全过滤器中定义的模式与请求的路径。解析器将把给定的模式变成一棵树的路径元素。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad214_643fc8c71437d0b2cc8c6914_%253Abankaccounts%253Aview.png)
解析器读取第一个字符作为SeparatorPathElement。然后它继续读取字符串字符,直到下一个分隔符,创建一个新的LiteralPathElement。
那么,用**作为模式时,哪里出了问题?
虽然有很多路径元素类型,但这里最有趣的是WildcardPathElement和WildcardTheRestPathElement,它们分别用字符串表示:*和/**。
WildcardPathElement匹配单个路径段中的零个或多个字符,而WildcardTheRestPathElement匹配零个或多个单独的路径段(包括分隔符)。
后者给了我们一个线索,说明在提交**作为模式时出了什么问题。在解析过程中,它寻找模式,但**并没有以预期的正斜杠开始。所以它没有成为WildcardTheRestPathElement,而是变成了两个连续的WildcardPathElements。
接下来,解析后的模式被用来与请求的URL匹配。路径应以正斜线开始,但通配符不与分隔符匹配。
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/66d08a68354d99e2e25ad211_644259043d142e4380b218d6_code-block-3.png)
这意味着返回的不是一个RequestMatchResult,而是一个null。因此,放在这个匹配器上的访问控制规则不会被应用到所请求的URL上。
Spring通过预加斜线解决了这个问题。换句话说,任何**模式都会变成/**,这意味着它可以被解析为WildcardTheRestPathElement,并且会返回一个RequestMatchResult,因为该模式现在与请求的URL相匹配。
漏洞还是API滥用?
这是否应该被认为是一个漏洞是值得商榷的,因为该代码是按预期工作的。问题基本上在于Spring文档中没有明确提到路径应该以分隔符开始。因此,这可以被认为是一个滥用API的案例,而不是一个错误或漏洞。