A closer look into the mvcRequestMatcher Spring vulnerability
On March 20th 2023, Spring Security Advisories published a blog post referencing an internally discovered vulnerability, CVE-2023-20860. No detailed information was disclosed, except that it was an access control issue concerning the use of mvcMatchers. Spring developers have remediated the issue, and a version update is advised.
Would you like a first hand experience? Try out the mission here.
As security is our main focus at Secure Code Warrior, we decided to take a deeper dive into this mvcRequestMatchers vulnerability and figure out where the core issue lies.
Spring provides the RequestMatcher interface to determine if a request matches a path pattern. Have a look at the code snippet below where the mvcMatchers helper method is used to register the endpoints along with their authentication and authorization requirements. For example, we can see that only users in the ADMIN role can access the /logs/audit endpoint.
MvcMisMatchers?
In Spring, ** is a pattern to match any number of directories and subdirectories in a URL. For example, /bankaccount/** would match all URLs starting with /bankaccount/, including subdirectories such as /bankaccount/dashboard/settings.
The * pattern is a pattern that matches any URL and has exactly one level of a subdirectory. For example, /bankaccount/* would match bankaccount/dashboard.
When configuring the matchers with *, Spring states that "a mismatch in pattern matching between Spring Security and Spr ing MVC" took place, creating the vulnerability.
Essentially, due to the lack of a separator in front of the double wildcard, the path doesn’t match an incoming request as all incoming requests are prepended by a slash. This means that the access control rules aren’t applied and allowing any unauthenticated user to access the resources.
Let’s have a look at the commit that fixed the issue.
The most prominent and important change is the addition of line 315, which fixes the bypassing of the authorization and authentication rules. It ensures that any path pattern that is submitted, is prepended with a forward slash (/).
404 match not found
When sending a web request to /bankaccounts/view the match method will parse and compare the patterns defined in the security filter with the requested path. The parser will turn the given pattern into a tree of path elements.
The parser reads the first character as a SeparatorPathElement. It then continues reading the string characters until the next separator, creating a new LiteralPathElement.
So where does it go wrong when using ** as the pattern?
While there are plenty of path element types, the most interesting ones here are the WildcardPathElement and the WildcardTheRestPathElement, with their respective string representations: * and /**.
A WildcardPathElement matches zero or more characters within a single path segment, while a WildcardTheRestPathElement matches zero or more path segments on their own (including the separators).
The latter one gives us a clue to what goes wrong when submitting ** as a pattern. During parsing it looks for patterns, but ** doesn’t start with the expected forward slash. So instead of becoming a WildcardTheRestPathElement, it becomes two consecutive WildcardPathElements.
Next, the parsed pattern is used to match against the requested URL. Paths are expected to start with a forward slash, but a wildcard does not match on separators.
This means that instead of a RequestMatchResult, a null is returned. Consequently, the access control rules placed on this matcher won’t be applied on the requested URL.
Spring fixed the issue by prepending a slash. In other words, any ** pattern becomes /**, meaning it can be parsed as a WildcardTheRestPathElement, and a RequestMatchResult will be returned as the pattern is now matching the requested URL.
Vulnerability or API misuse?
It’s debatable whether this should be considered a vulnerability, as the code works as intended. The issue basically lies in the fact that the Spring documentation lacks an explicit mention that paths should start with a separator. Therefore, it could be considered more of a case of API misuse, instead of a bug or vulnerability.
On March 20th 2023, Spring Security Advisories published a blog post referencing an internally discovered vulnerability, CVE-2023-20860. No detailed information was disclosed, except that it was an access control issue concerning the use of `mvcMatchers`. Spring developers have remediated the issue, and a version update is advised. Since security is our main focus at Secure Code Warrior, we decided to take a deeper dive into this mvcRequestMatchers vulnerability and figure out where the core issue lies.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo
Brysen is a software developer at Secure Code Warrior with a focus on writing secure code.
On March 20th 2023, Spring Security Advisories published a blog post referencing an internally discovered vulnerability, CVE-2023-20860. No detailed information was disclosed, except that it was an access control issue concerning the use of mvcMatchers. Spring developers have remediated the issue, and a version update is advised.
Would you like a first hand experience? Try out the mission here.
As security is our main focus at Secure Code Warrior, we decided to take a deeper dive into this mvcRequestMatchers vulnerability and figure out where the core issue lies.
Spring provides the RequestMatcher interface to determine if a request matches a path pattern. Have a look at the code snippet below where the mvcMatchers helper method is used to register the endpoints along with their authentication and authorization requirements. For example, we can see that only users in the ADMIN role can access the /logs/audit endpoint.
MvcMisMatchers?
In Spring, ** is a pattern to match any number of directories and subdirectories in a URL. For example, /bankaccount/** would match all URLs starting with /bankaccount/, including subdirectories such as /bankaccount/dashboard/settings.
The * pattern is a pattern that matches any URL and has exactly one level of a subdirectory. For example, /bankaccount/* would match bankaccount/dashboard.
When configuring the matchers with *, Spring states that "a mismatch in pattern matching between Spring Security and Spr ing MVC" took place, creating the vulnerability.
Essentially, due to the lack of a separator in front of the double wildcard, the path doesn’t match an incoming request as all incoming requests are prepended by a slash. This means that the access control rules aren’t applied and allowing any unauthenticated user to access the resources.
Let’s have a look at the commit that fixed the issue.
The most prominent and important change is the addition of line 315, which fixes the bypassing of the authorization and authentication rules. It ensures that any path pattern that is submitted, is prepended with a forward slash (/).
404 match not found
When sending a web request to /bankaccounts/view the match method will parse and compare the patterns defined in the security filter with the requested path. The parser will turn the given pattern into a tree of path elements.
The parser reads the first character as a SeparatorPathElement. It then continues reading the string characters until the next separator, creating a new LiteralPathElement.
So where does it go wrong when using ** as the pattern?
While there are plenty of path element types, the most interesting ones here are the WildcardPathElement and the WildcardTheRestPathElement, with their respective string representations: * and /**.
A WildcardPathElement matches zero or more characters within a single path segment, while a WildcardTheRestPathElement matches zero or more path segments on their own (including the separators).
The latter one gives us a clue to what goes wrong when submitting ** as a pattern. During parsing it looks for patterns, but ** doesn’t start with the expected forward slash. So instead of becoming a WildcardTheRestPathElement, it becomes two consecutive WildcardPathElements.
Next, the parsed pattern is used to match against the requested URL. Paths are expected to start with a forward slash, but a wildcard does not match on separators.
This means that instead of a RequestMatchResult, a null is returned. Consequently, the access control rules placed on this matcher won’t be applied on the requested URL.
Spring fixed the issue by prepending a slash. In other words, any ** pattern becomes /**, meaning it can be parsed as a WildcardTheRestPathElement, and a RequestMatchResult will be returned as the pattern is now matching the requested URL.
Vulnerability or API misuse?
It’s debatable whether this should be considered a vulnerability, as the code works as intended. The issue basically lies in the fact that the Spring documentation lacks an explicit mention that paths should start with a separator. Therefore, it could be considered more of a case of API misuse, instead of a bug or vulnerability.
On March 20th 2023, Spring Security Advisories published a blog post referencing an internally discovered vulnerability, CVE-2023-20860. No detailed information was disclosed, except that it was an access control issue concerning the use of mvcMatchers. Spring developers have remediated the issue, and a version update is advised.
Would you like a first hand experience? Try out the mission here.
As security is our main focus at Secure Code Warrior, we decided to take a deeper dive into this mvcRequestMatchers vulnerability and figure out where the core issue lies.
Spring provides the RequestMatcher interface to determine if a request matches a path pattern. Have a look at the code snippet below where the mvcMatchers helper method is used to register the endpoints along with their authentication and authorization requirements. For example, we can see that only users in the ADMIN role can access the /logs/audit endpoint.
MvcMisMatchers?
In Spring, ** is a pattern to match any number of directories and subdirectories in a URL. For example, /bankaccount/** would match all URLs starting with /bankaccount/, including subdirectories such as /bankaccount/dashboard/settings.
The * pattern is a pattern that matches any URL and has exactly one level of a subdirectory. For example, /bankaccount/* would match bankaccount/dashboard.
When configuring the matchers with *, Spring states that "a mismatch in pattern matching between Spring Security and Spr ing MVC" took place, creating the vulnerability.
Essentially, due to the lack of a separator in front of the double wildcard, the path doesn’t match an incoming request as all incoming requests are prepended by a slash. This means that the access control rules aren’t applied and allowing any unauthenticated user to access the resources.
Let’s have a look at the commit that fixed the issue.
The most prominent and important change is the addition of line 315, which fixes the bypassing of the authorization and authentication rules. It ensures that any path pattern that is submitted, is prepended with a forward slash (/).
404 match not found
When sending a web request to /bankaccounts/view the match method will parse and compare the patterns defined in the security filter with the requested path. The parser will turn the given pattern into a tree of path elements.
The parser reads the first character as a SeparatorPathElement. It then continues reading the string characters until the next separator, creating a new LiteralPathElement.
So where does it go wrong when using ** as the pattern?
While there are plenty of path element types, the most interesting ones here are the WildcardPathElement and the WildcardTheRestPathElement, with their respective string representations: * and /**.
A WildcardPathElement matches zero or more characters within a single path segment, while a WildcardTheRestPathElement matches zero or more path segments on their own (including the separators).
The latter one gives us a clue to what goes wrong when submitting ** as a pattern. During parsing it looks for patterns, but ** doesn’t start with the expected forward slash. So instead of becoming a WildcardTheRestPathElement, it becomes two consecutive WildcardPathElements.
Next, the parsed pattern is used to match against the requested URL. Paths are expected to start with a forward slash, but a wildcard does not match on separators.
This means that instead of a RequestMatchResult, a null is returned. Consequently, the access control rules placed on this matcher won’t be applied on the requested URL.
Spring fixed the issue by prepending a slash. In other words, any ** pattern becomes /**, meaning it can be parsed as a WildcardTheRestPathElement, and a RequestMatchResult will be returned as the pattern is now matching the requested URL.
Vulnerability or API misuse?
It’s debatable whether this should be considered a vulnerability, as the code works as intended. The issue basically lies in the fact that the Spring documentation lacks an explicit mention that paths should start with a separator. Therefore, it could be considered more of a case of API misuse, instead of a bug or vulnerability.
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demo
Try out our mission to experience the impact for yourself and learn how to avoid making a similar mistake.
Try it NowBrysen is a software developer at Secure Code Warrior with a focus on writing secure code.
On March 20th 2023, Spring Security Advisories published a blog post referencing an internally discovered vulnerability, CVE-2023-20860. No detailed information was disclosed, except that it was an access control issue concerning the use of mvcMatchers. Spring developers have remediated the issue, and a version update is advised.
Would you like a first hand experience? Try out the mission here.
As security is our main focus at Secure Code Warrior, we decided to take a deeper dive into this mvcRequestMatchers vulnerability and figure out where the core issue lies.
Spring provides the RequestMatcher interface to determine if a request matches a path pattern. Have a look at the code snippet below where the mvcMatchers helper method is used to register the endpoints along with their authentication and authorization requirements. For example, we can see that only users in the ADMIN role can access the /logs/audit endpoint.
MvcMisMatchers?
In Spring, ** is a pattern to match any number of directories and subdirectories in a URL. For example, /bankaccount/** would match all URLs starting with /bankaccount/, including subdirectories such as /bankaccount/dashboard/settings.
The * pattern is a pattern that matches any URL and has exactly one level of a subdirectory. For example, /bankaccount/* would match bankaccount/dashboard.
When configuring the matchers with *, Spring states that "a mismatch in pattern matching between Spring Security and Spr ing MVC" took place, creating the vulnerability.
Essentially, due to the lack of a separator in front of the double wildcard, the path doesn’t match an incoming request as all incoming requests are prepended by a slash. This means that the access control rules aren’t applied and allowing any unauthenticated user to access the resources.
Let’s have a look at the commit that fixed the issue.
The most prominent and important change is the addition of line 315, which fixes the bypassing of the authorization and authentication rules. It ensures that any path pattern that is submitted, is prepended with a forward slash (/).
404 match not found
When sending a web request to /bankaccounts/view the match method will parse and compare the patterns defined in the security filter with the requested path. The parser will turn the given pattern into a tree of path elements.
The parser reads the first character as a SeparatorPathElement. It then continues reading the string characters until the next separator, creating a new LiteralPathElement.
So where does it go wrong when using ** as the pattern?
While there are plenty of path element types, the most interesting ones here are the WildcardPathElement and the WildcardTheRestPathElement, with their respective string representations: * and /**.
A WildcardPathElement matches zero or more characters within a single path segment, while a WildcardTheRestPathElement matches zero or more path segments on their own (including the separators).
The latter one gives us a clue to what goes wrong when submitting ** as a pattern. During parsing it looks for patterns, but ** doesn’t start with the expected forward slash. So instead of becoming a WildcardTheRestPathElement, it becomes two consecutive WildcardPathElements.
Next, the parsed pattern is used to match against the requested URL. Paths are expected to start with a forward slash, but a wildcard does not match on separators.
This means that instead of a RequestMatchResult, a null is returned. Consequently, the access control rules placed on this matcher won’t be applied on the requested URL.
Spring fixed the issue by prepending a slash. In other words, any ** pattern becomes /**, meaning it can be parsed as a WildcardTheRestPathElement, and a RequestMatchResult will be returned as the pattern is now matching the requested URL.
Vulnerability or API misuse?
It’s debatable whether this should be considered a vulnerability, as the code works as intended. The issue basically lies in the fact that the Spring documentation lacks an explicit mention that paths should start with a separator. Therefore, it could be considered more of a case of API misuse, instead of a bug or vulnerability.
Table of contents
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Secure by Design: Defining Best Practices, Enabling Developers and Benchmarking Preventative Security Outcomes
In this research paper, Secure Code Warrior co-founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., along with expert contributors, Chris Inglis, Former US National Cyber Director (now Strategic Advisor to Paladin Capital Group), and Devin Lynch, Senior Director, Paladin Global Institute, will reveal key findings from over twenty in-depth interviews with enterprise security leaders including CISOs, a VP of Application Security, and software security professionals.
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
Finding meaningful data on the success of Secure-by-Design initiatives is notoriously difficult. CISOs are often challenged when attempting to prove the return on investment (ROI) and business value of security program activities at both the people and company levels. Not to mention, it’s particularly difficult for enterprises to gain insights into how their organizations are benchmarked against current industry standards. The President’s National Cybersecurity Strategy challenged stakeholders to “embrace security and resilience by design.” The key to making Secure-by-Design initiatives work is not only giving developers the skills to ensure secure code, but also assuring the regulators that those skills are in place. In this presentation, we share a myriad of qualitative and quantitative data, derived from multiple primary sources, including internal data points collected from over 250,000 developers, data-driven customer insights, and public studies. Leveraging this aggregation of data points, we aim to communicate a vision of the current state of Secure-by-Design initiatives across multiple verticals. The report details why this space is currently underutilized, the significant impact a successful upskilling program can have on cybersecurity risk mitigation, and the potential to eliminate categories of vulnerabilities from a codebase.
Resources to get you started
Revealed: How the Cyber Industry Defines Secure by Design
In our latest white paper, our Co-Founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., sat down with over twenty enterprise security leaders, including CISOs, AppSec leaders and security professionals, to figure out the key pieces of this puzzle and uncover the reality behind the Secure by Design movement. It’s a shared ambition across the security teams, but no shared playbook.
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
