StrictHttpFirewall allows "//path" "//path//path" patterns.

[hatanaka-akihiro]

Summary

StrictHttpFirewall checks non-normalized URL containing double slash (//).
However, I think this checking algorithm is ambiguous.

Actual Behavior

• /path//path -> 500 error
• //path/path -> OK
• //path//path -> OK

Is this intended specification? or bug?

Expected Behavior

• /path//path -> 500 error
• //path/path -> 500 error ?
• //path//path -> 500 error

Version

Spring Security 5.0.1

Comment

StrictHttpFirewall.isNormalized(String)

		if (path.indexOf("//") > 0) {
			return false;
		}

>=0 is right?
or lastIndexOf("//") ?

[rwinch]

Thanks for the report! I have pushed a fix for this

[opncow]

We are running into problems due to this change as the URL that gets checked in StrictHttpFirewall has an added double slash at the beginning that was not sent. The added slash seems to ultimately come from the Apache Coyote Request that is wrapped in the passed in HttpServletRequest (RequestFacade).

To make it clear: We are using embedded Tomcat in version 8.5.29 (the default in Spring Boot2.0.1.RELEASE). Let's say I'm sending the following GET request:

GET https://somedomain:8443/test-service/test

The following happens:

• At some point, StrictHttpFirewall does its checks
• It enters StrictHttpFirewall#isNormalized(HttpServletRequest request)
• The HttpServletRequest implementation that is used is org.apache.catalina.connector.RequestFacade
• RequestFacade wraps org.apache.coyote.Request (via org.apache.catalina.connector.Request)
• The isNormalized method calls request.getRequestURI() which in the end gets answered via coyoteRequest.requestURI().toString()
• For some reason, the result is //test instead of /test
• isNormalized fails due to that since Spring Security 5.0.4.RELEASE which seems to have the change from this issue here

Any advice besides downgrading to Spring Security 5.0.3.RELEASE? Is there something wrong on our side?

[rwinch]

@opncow Thanks for the feedback. This issue is closed so the best way to proceed is to create a new ticket so we can track the problem. Please provide details on how to reproduce in the issue. If we cannot reproduce the problem we cannot advise or provide a fix.

[opncow]

@rwinch Okay, I thought you might simply reopen it. I will create a separate issue asap and provide a minimal example project there to reproduce it.

[rwinch]

As an FYI we cannot reopen tickets once we have done a release because that would change the changelog for a release.

[opncow]

Okay, to clear this one up: It actually was a misconfiguration of our NGINX reverse proxy... :-) Thanks for pointing us on it with this change and sorry for the noise!

[rwinch]

@opncow Thanks for the follow up! I'm glad you got the problem resolved