Skip to content

StrictFirewallServerWebExchange should still protect when request is mutated #16978

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
siddhivinayak-sk opened this issue Apr 22, 2025 · 1 comment
Assignees
Labels
in: web An issue in web modules (web, webmvc) type: bug A general bug
Milestone

Comments

@siddhivinayak-sk
Copy link

Describe the bug

With Spring Boot 3.3.4 and Spring Cloud 2024.0.1 along with spring-security-web dependency, inside implementation of custom WebFilter, the exchange object provided of StrictFirewallServerWebExchange type.

This class StrictFirewallServerWebExchange is defined at org.springframework.security.web.server.firewall.StrictServerWebExchangeFirewall and it has private implementation of decorators and builds for ServerWebExchange and ServerHttpRequest.

It is supposed to provide mutation on request object by using method like:

        val buildRequest = request
                .mutate()
                .header("xyz", "abc")
                .build()

Expected behavior is after mutation it should return instance of StrictFirewallHttpRequest but it returns org.springframework.http.server.reactive.DefaultServerHttpRequestBuilder$MutatedServerHttpRequest.

This creates issue whenever request is modified using WebFilter, there is no impact of changes.

To Reproduce

  1. Create a sample reactive spring boot application with spring security, Http firewall
  2. Add a pre WebFilter
  3. Try to mutate exchange like this:
        var buildRequest = exchange.request
                .mutate()
                .header("xyz", "abc")
                .build()
        var buildExchange = exchange.mutate().request(buildRequest).build()
    
  4. Either check returned buildExchange type or do the chain.filter(buildExchange) and see the endpoint result.

Expected behavior

If we do mutation like (without adding header), it results correct instance:

        var buildRequest = exchange.request
                .mutate()
                .build()

Image

Similarly, when we modify request and a header like:
var buildRequest = exchange.request .mutate() .header("xyz", "abc") .build() var buildExchange = exchange.mutate().request(buildRequest).build()

It should also return correct instance (of StrictFirewallHttpRequest) but it returns:

Image

While investigation, found that StrictFirewallBuilder.header(String headerName, String... headerValues) method calls same method on delegated object which returns DefaultServerHttpRequestBuilder type while ideally this method should wrap into StrictFirewallBuilder type:

                public ServerHttpRequest.Builder header(String headerName, String... headerValues) {
                    return this.delegate.header(headerName, headerValues);
                }

@siddhivinayak-sk siddhivinayak-sk added status: waiting-for-triage An issue we've not yet triaged type: bug A general bug labels Apr 22, 2025
@jzheaux jzheaux self-assigned this Apr 29, 2025
@jzheaux jzheaux closed this as completed in e48f26e May 2, 2025
@jzheaux jzheaux changed the title With Spring Security mutation on StrictFirewallHttpRequest should return StrictFirewallHttpRequest while it returns DefaultServerHttpRequestBuilder$MutatedServerHttpRequest in WebFilter StrictFirewallServerWebExchange should still protect when request is mutated May 2, 2025
@jzheaux jzheaux added in: web An issue in web modules (web, webmvc) and removed status: waiting-for-triage An issue we've not yet triaged labels May 2, 2025
@jzheaux jzheaux added this to the 6.3.10 milestone May 2, 2025
@jzheaux
Copy link
Contributor

jzheaux commented May 2, 2025

Thanks, @siddhivinayak-sk, for the report. I've pushed a fix to 6.3.x, 6.4.x, and main. It should be available in the next point release for each.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web An issue in web modules (web, webmvc) type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants