You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We upgraded to Spring Boot 3.3.5, which brought in Spring Security 6.3.4. This is the latest. We are now having issues where requests with certain encoded characters in the URLs are rejected.
On further investigation, there was a change committed to the spring-security-web package on Oct 3, 2024 by Rob Winch that seems to be the culprit. The commit hash is 0e257b5.
The ServerWebExchangeFirewall is explicitly integrated into the WebFilterChainProxy class. It is hardcoded as a field in that class, and is not provided via dependency injection. This means it cannot be overridden, which means its various settings cannot be customized.
The documentation that was also added in this commit says that you can define a bean of this type to override it. However, not only does this fail to work in practice, upon looking at the code it is impossible to see how it would work in theory either. As was previously mentioned, the firewall is hard-coded as an instance field and is not provided via DI.
Basically, this means that there is no way to permit these encoded characters. Any users of spring who have such characters in their URIs are SOL. This is a MAJOR breaking change to existing behavior with no remediation or workaround.
To Reproduce
Send a request with an encoded backslash in the URI (%5C) to a spring webflux application.
Expected behavior
In the servlet stack, we can define a bean of type HttpFirewall (and its sub-class StringHttpFirewall), and it will become the firewall implementation of the application. This should be possible with the ServerWebExchangeFirewall (and its sub-type, StrictServerWebExchangeFirewall).
Thanks for the report @craigmiller160 This appears to be a duplicate of #15974 which has a workaround posted on it
In the event that you are getting an UnsupportedOperationException and why you are trying to customize it, #15989 and the workaround (#15989 (comment)) may be of interest for you.
Describe the bug
We upgraded to Spring Boot 3.3.5, which brought in Spring Security 6.3.4. This is the latest. We are now having issues where requests with certain encoded characters in the URLs are rejected.
On further investigation, there was a change committed to the spring-security-web package on Oct 3, 2024 by Rob Winch that seems to be the culprit. The commit hash is 0e257b5.
The ServerWebExchangeFirewall is explicitly integrated into the WebFilterChainProxy class. It is hardcoded as a field in that class, and is not provided via dependency injection. This means it cannot be overridden, which means its various settings cannot be customized.
The documentation that was also added in this commit says that you can define a bean of this type to override it. However, not only does this fail to work in practice, upon looking at the code it is impossible to see how it would work in theory either. As was previously mentioned, the firewall is hard-coded as an instance field and is not provided via DI.
Basically, this means that there is no way to permit these encoded characters. Any users of spring who have such characters in their URIs are SOL. This is a MAJOR breaking change to existing behavior with no remediation or workaround.
To Reproduce
Send a request with an encoded backslash in the URI (%5C) to a spring webflux application.
Expected behavior
In the servlet stack, we can define a bean of type HttpFirewall (and its sub-class StringHttpFirewall), and it will become the firewall implementation of the application. This should be possible with the ServerWebExchangeFirewall (and its sub-type, StrictServerWebExchangeFirewall).
Sample
https://github.com/craigmiller160/webflux-firewall-demo
The text was updated successfully, but these errors were encountered: