仔细研究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的案例，而不是一个错误或漏洞。
2023年3月20日，Spring Security Advisories发表了一篇博文，提到了一个内部发现的漏洞CVE-2023-20860。没有披露详细的信息，只是说这是一个关于使用`mvcMatchers'的访问控制问题。Spring开发者已经修复了这个问题，并建议进行版本更新。由于安全是我们在Secure Code Warrior ，我们决定深入研究这个mvcRequestMatchers漏洞，找出核心问题所在。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示
Brysen是Secure Code Warrior 的一名软件开发人员，专注于编写安全代码。
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的案例，而不是一个错误或漏洞。
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的案例，而不是一个错误或漏洞。
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的案例，而不是一个错误或漏洞。
资源
OpenText 应用程序安全性的强大功能 + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
安全代码培训主题和内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
资源
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
