ForwardedHeaderFilter should reject invalid requests

[ravihansa3000]

Hi, our Spring Boot application using Spring Boot 3.1.4 which includes spring-web:6.0.12 started throwing 5xx due to a malformed X-Forwarded-For header in the requests that were returned with 5xx and this error in our logs; java.lang.IllegalArgumentException: Failed to parse a port from "forwarded"-type headers.

I would suggest introducing a mechanism to skip extracting "forwarded"-type headers in ForwardedHeaderFilter when the header format is invalid. Our service SLOs are impacted by this issue and such incidents attract unnecessary attention. Thanks!

[bclozel]

Hello @ravihansa3000, thanks for reaching out.

It's not clear from your description whether this is something that used to work with a previous Spring version or if this problem appeared because invalid requests started coming in production. Can you elaborate?

Can you give an example of such invalid request? Do you happen to know where this comes from? Is there a specific proxy or client that we should know about? Knowing if this is a custom client or some well-known product would really help.

[rstoyanchev]

In addition, please provide a stacktrace that shows the location of the failure, and also try with the latest 6.0.15 just in case.

[ravihansa3000]

Hi @bclozel I don't think this is a regression and the problem appeared in prod when Forwarded header contained a malformed value like; "for=[a:" We don't know whether this payload was maliciously formed or due to a faulty intermediary gateway. The app follows a standard deployment in AWS infrastructure.

@rstoyanchev This behavior is present in 6.0.15 as well and the exception is raised in

spring-framework/spring-web/src/main/java/org/springframework/web/util/UriComponentsBuilder.java

Line 904 in f32e749

throw new IllegalArgumentException("Invalid IPv4 address: " + rawValue);

[bclozel]

We should reject invalid requests right away instead of throwing IllegalStateException or IllegalArgumentException instance. This will align the behavior here with HttpWebHandlerAdapter on the WebFlux side.