Spring Security fixes two high-severity flaws – CVE-2023-34034 & CVE-2023-34035

Spring Security, with its robust authentication and access-control framework, has earned its stripes as the standard-bearer for securing Spring-based applications. It not only provides authentication and authorization for Java applications but is also known for its immense adaptability, effortlessly meeting a wide array of custom requirements. However, like every stronghold, Spring Security has also seen the presence of vulnerabilities that can be exploited, two of which we will be discussing in this article: CVE-2023-34034 and CVE-2023-34035.

CVE-2023-34034: WebFlux Security Bypass With Un-Prefixed Double Wildcard Pattern

The first vulnerability, CVE-2023-34034, has a CVSS score of 8.8 and occurs when “**” is used as a pattern in Spring Security configuration for WebFlux, leading to a mismatch in pattern matching between Spring Security and Spring WebFlux and potentially opening up a route for a security bypass.

The affected Spring Security versions are 6.1.0 to 6.1.1, 6.0.0 to 6.0.4, 5.8.0 to 5.8.4, 5.7.0 to 5.7.9, and 5.6.0 to 5.6.11. The solution lies in the use of Spring Security versions containing fixes for this vulnerability: 6.1.2+, 6.0.5+, 5.8.5+, 5.7.10+, and 5.6.12+; these require Spring Framework versions 6.0.11+, 5.3.29+, and 5.2.25+.

CVE-2023-34035: Authorization rules can be misconfigured when using multiple servlets

The second vulnerability, CVE-2023-34035, presents itself when Spring Security versions 5.8 prior to 5.8.5, 6.0 prior to 6.0.5, and 6.1 prior to 6.1.2 are employed. These versions are susceptible to a misconfiguration of authorization rules if the application uses requestMatchers(String) and multiple servlets – with one of them being Spring MVC’s DispatcherServlet, a component that maps HTTP endpoints to methods on @Controller-annotated classes.

An application is considered vulnerable when it has Spring MVC on the classpath, secures more than one servlet in a single application (one of them being Spring MVC’s DispatcherServlet), and uses requestMatchers(String) to refer to endpoints that are not Spring MVC endpoints. However, if Spring MVC is not on the classpath, or if the application secures no servlets other than Spring MVC’s DispatcherServlet, or uses requestMatchers(String) solely for Spring MVC endpoints, then the application remains invulnerable.

Mitigation strategies entail upgrading to 5.8.5 for 5.8.x users, to 6.0.5 for 6.0.x users, and to 6.1.2 for 6.1.x users. Additionally, the error message at startup time provides vital clues. For instance, if requestMatchers(String) points to a non-Spring MVC endpoint, /endpoint, it should be changed to requestMatchers(new AntPathRequestMatcher(“/endpoint”)).

While Spring Security continues to serve as an adept and flexible shield for Spring-based applications, these vulnerabilities underscore the significance of continuous monitoring and timely updates in maintaining the security integrity of an application. In the realm of cybersecurity, one cannot afford to rest on laurels; it is an ongoing crusade against potential threats, vulnerabilities, and exploits.