SEC-2981: AbstractRetryEntryPoint infinitive redirection loop when secured channel is required.

Jakub Narloch (Migrated from SEC-2981) said:

Steps to reproduce:

• Run your application server on custom port ie. 7080 (or connect to it through proxy/tunnel - this is in fact the way we have found this problem)
• Enforce secured channel:

 http.requiresChannel()
                    .anyRequest()
                    .requiresSecure();

• Make the request for non root path: '/webapp'

As a result the client is being endlessly redirected to relative path resulting in the path being consecutive appended to current url e.g. : '/webapp/webapp/webapp/webapp/webapp/webapp/webapp/webapp/webapp/webapp/webapp'

The reason why this happens is the handling of the port mappings in AbstractRetryEntryPoint:
https://github.com/spring-projects/spring-security/blob/master/web/src/main/java/org/springframework/security/web/access/channel/AbstractRetryEntryPoint.java#L54

if (redirectPort != null) {
    boolean includePort = redirectPort.intValue() != standardPort;

    redirectUrl = scheme + request.getServerName()
            + ((includePort) ? (":" + redirectPort) : "") + redirectUrl;
}

Proposition would be to return http 400 or 406 status code in cases that there is no valid port.

Yes I agree that in general this problem would be caused by incorrect port mappings between HTTP and HTTPS and this is only a matter of configuration in the PortMapper, although in our cases the client is connecting through proxy on non default port and is redirected to an invalid path without protocol switch.

Start with web/src/main/java/org/springframework/security/web/access/channel/AbstractRetryEntryPoint.java at the port-mapping logic around line 54. Reproduce the issue with requiresChannel().anyRequest().requiresSecure(), a custom server port, and a non-root path such as /webapp. Done means an invalid port mapping no longer produces repeated relative redirects, with the resulting behavior matching the agreed HTTP error or redirect handling.