CVE-2023-34034 is another authorization bypass in Spring Security. Like CVE-2022-31692 it’s nasty because it allows completely unrestricted access to supposedly protected resources. Also like CVE-2022-31692 it requires very specific configuration to be vulnerable and is easily fixed.
This post demonstrates the vulnerability, the problem configuration and suggested fixes. A demonstration vulnerable application is on GitHub.
CVE-2022-31692 is a vulnerability in Spring Security that allows authorization bypass when running with specific configurations. The good news is that only very specific configurations are exploitable. However, if you’ve configured Spring Security in this way, attackers can access protected resources without authorization.
The Spring4Shell (CVE-2022-22965) critical severity vulnerability in Spring Framework allows remote code execution (RCE). At time of writing, it can be exploited only in very specific scenarios. However, Spring have made a patch available (Spring Framework version 5.3.18 and 5.2.20) and I strongly advise you to take them, even if you’re not running the exploitable setup.
Spring WebClient is the reactive replacement for the legacy RestTemplate. It has a more modern fluent API and first class support for Reactive Streams. This means it supports non-blocking, asynchronous responses.
However, the reactive WebClient does not yet have the mature test support that RestTemplate now has. There is not yet a standard recipe to test Spring WebClient applications. No doubt support will be improved in future versions but for now, here’s what works for me.
CRUD REST services are the backbone of a microservice architecture. If we want to use microservices rather than monolithic applications, it’s essential that we can create a basic service with a minimum of effort. Spring Boot can be used to quickly create and deploy a new web service. Spring Data REST can be used to build out the REST interface based on a database entity model. Using both together allows us to create a running RESTful web service with zero custom Java code and no tricky XML.
This article describes how to build a RESTful web service as an executable JAR that provides CRUD operations against a single MySQL database table.
This demo can be downloaded from GitHub in the Spanners Demo Application version 4.0 (spanners-api module). You can run the working example as a docker-compose stack, along with the associated MySQL database and the Spring MVC web app that consumes the service (see the previous post on docker-compose for details on how to run this).
A standard Spring Security configuration uses username / password based authentication. This always presents a tricky problem: how to securely store a user’s password in such a way that it can’t be read by anyone with access to our database. It’s naive to assume that our password database is 100% secure, just ask Adobe, Sony, Ashley Madison, and every other large organization that has had their database breached. Even if the database isn’t ‘breached’ or ‘leaked’, legitimate database admins or sys admins still have access to user passwords. A database containing user passwords is a liability that we’d rather not have.
The standard solution to this problem is store store a hash of the password rather than the plain text or even encrypted text. I don’t want to focus on why this is good or how it works as many others have done this already. I’ve found no better discussion of this (and password management in general) than Troy Hunt’s post on Everything you ever wanted to know about building a secure password reset feature.
Getting the details right when implementing password storage is critical. Some hash algorithms are vulnerable or just not suited to password hashing. If the salt is too short or predictable, it may be possible to retrieve the password from the hash. Any number of subtle bugs in coding could result in a password database that is vulnerable in one way or another. Fortunately, Spring Security includes password hashing out of the box. What’s more, since version 3.1, Spring Security automatically takes care of salting too.
A common unit test scenario for Spring / Spring MVC applications is to verify behavior when logged in as a particular user. The new spring-security-test library available with Spring Security version 4 makes testing user access controls in Spring and Spring MVC applications far simpler.
In less than five minutes and just three Maven commands, I was able to create, compile and run a fully working example Spring MVC application.
Spring Web Services (Spring-WS) are a neat way of declaratively creating SOAP web services using Spring with a minimum of boilerplate code usually associated with web services. I’d recommend it as the best way to create web services for a Spring application. When it comes to WS-Security (message encryption, authentication, signatures and so on) it is absolutely vital. It simplifies the very complicated business of securing messages to a few lines of declarative code.
I found the documentation provided by Spring on writing Spring-WS services and securing Spring-WS services very in depth and thorough but I’ve not yet found a good simple example app. This demo is about the simplest possible web service with the most standard WS-Security features enabled.