Regression: ForwardedHeaderFilter no longer support IPv6

[czubin]

Affects:: spring-web 5.3.6

After updating from spring 5.2.8 to 5.3.6 we noticed that ForwardedHeaderFilter would throw:

java.lang.IllegalArgumentException: Invalid IPv4 address: 2a02:1810:84ae:d800:c8da:d498:64ec:6edb
	at org.springframework.web.util.UriComponentsBuilder.parseForwardedFor(UriComponentsBuilder.java:363)
	at org.springframework.web.filter.ForwardedHeaderFilter$ForwardedHeaderExtractingRequest.<init>(ForwardedHeaderFilter.java:246)

The code before:

String baseUrl = this.scheme + "://" + this.host + (port == -1 ? "" : ":" + port);    
Supplier<HttpServletRequest> delegateRequest = () -> (HttpServletRequest) getRequest();    
this.forwardedPrefixExtractor = new ForwardedPrefixExtractor(delegateRequest, baseUrl);

The code as is:

this.remoteAddress = UriComponentsBuilder.parseForwardedFor(request, request.getRemoteAddress());

String baseUrl = this.scheme + "://" + this.host + (port == -1 ? "" : ":" + port);
Supplier<HttpServletRequest> delegateRequest = () -> (HttpServletRequest) getRequest();
this.forwardedPrefixExtractor = new ForwardedPrefixExtractor(delegateRequest, baseUrl);```

The invocation of UriComponentsBuilder.parseForwardedFor only support IPv4.

[rstoyanchev]

The line where the IAE error is raised:

this.remoteAddress = UriComponentsBuilder.parseForwardedFor(request, request.getRemoteAddress());

was added in support of "X-Forward-For" and "Forwarded for:" as part of #23582 with commits 883ad09 and d627f60 while the validation was added in #26748.

The address "2a02:1810:84ae:d800:c8da:d498:64ec:6edb" is indeed invalid. It should have surrounding square brackets. What I'm not sure is is exactly what happened before. I'm guessing that the header causing the issue simply wasn't parsed. Can you please provide the relevant headers in their entirety?

[czubin]

You are correct. Seems I'll have to file a bug with the gateway vendor.

Below the trace (I've removed some parts of the IP's)

"forwarded": [
  "by=193.???.???.???:8444; for=2a02:1812:240b:5465:1c8a:8ab9:8d05:bca7; host=???.api.???.com; proto=https",
  "for=164.???.???.;host=???.???.eu;proto=https;proto-version="
],
"x-forwarded-for": [
  "2a02:1812:240b:5465:1c8a:8ab9:8d05:bca7, 104.???.???.???"
],```

[poutsma]

Closing as invalid.

[PatrickGotthard]

Why was this issue closed as invalid? The problem still exists and older versions accepted such IPv6 addresses.
I know the IPv6 addresses you mentioned are not RFC-compliant (they should be wrapped in "[XYZ]") but isn't it possible to be a little bit more failure-tolerant? Maybe just drop the header instead of failing the complete request?

Seems like the Spring Cloud Gateway team solved the issue: spring-cloud/spring-cloud-gateway#2217

[rstoyanchev]

Unfortunately in this case it is not possible to be lenient due to ambiguity since what comes after the last ":" could be part of the host address or a port. The change in Spring Cloud Gateway is to format IPv6 addresses correctly for forwarded headers it creates, and not for parsing forwarded headers.

[PatrickGotthard]

But what should the user do when there's no chance to fix the incorrect header (e.g. the wrong headers are created by the Service Providers infrastructure)?

In my case I only need the original hostname (X-Forwarded-Host) but the ForwardedHeaderFilter also tries to parse the IP Address and then the complete request crashes. May it be an option to make the ForwardedHeaderFilter configurable, e.g. that you could configure what headers to parse and how lenient it should be?

[rstoyanchev]

X-Forwarded-Host contains host and port, so parsing is required to get the original hostname. Lenient parsing is not possible and such an option would be misleading at best. For a very specific case, if you want or can make certain assumptions, create add your own filter ordered ahead of ForwaredHeaderFilter to modify the X-Forwarded-Host header.