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.
Jakub Narloch (Migrated from SEC-2981) said:
Steps to reproduce:
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
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.