A closer look into the mvcRequestMatcher Spring vulnerability
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
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.
CVE-2023-20860 Mission
Try out our mission to experience the impact for yourself and learn how to avoid making a similar mistake.
Brysen Ackx
Brysen is a software developer at Secure Code Warrior with a focus on writing secure code.
Related Articles We Recommend
.png)
Related Articles We Recommend
Dive into onto our latest secure coding insights on the blog.
Our extensive resource library aims to empower the human approach to secure coding upskilling.
Get the latest research on developer-driven security
Our extensive resource library is full of helpful resources from whitepapers to webinars to get you started with developer-driven secure coding. Explore it now.
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.
