spring-security-web is not consistence with % and ;

[patelneelj]

Describe the bug
In the spring version: 5+ (5.1.9 spring-security-web) for % and ;

1. spring framework is throwing full stack trace.
2. with Http response code 500 instead of 400

To Reproduce
If I send input filed like for GET /Users/{name} -- Name of User = "User1;" or "User2%" we can see the following response with full stack trace information.

With this //, \, or // without any customization, spring-security by default responding with 400 response code with out any stack trace. Based on my investigation I found that with for "%" and ";" has different workflows then other special chars like "//", "\" etc . It is going through StrictHttpFirewall.rejectedBlacklistedUrls() which is a private method of part of the Spring-Security-web framework.

Expected behavior
Same like "//" or'/'other special character, for % and ;

1. It should not throw a full stack trace
2. Response code should be 400 instead of 500 for

Example

1. For "//"
   

2. For % or ;
   

[rwinch]

Thanks for the report. This appears to be a duplicate of gh-5007 which was resolved via gh-7052. Starting in Spring Security 5.4 you will be able to configure the RequestRejectedHandler by exposing it as a Bean with something like HttpStatusRequestRejectedHandler to change how rejected requests are processed.

Can you confirm this is a duplicate?

[patelneelj]

@rwinch Thank you for your response. I believe the one which you are talking about #5007 is only dealing with "//" or '\'
This is some special edge case, where for "%" and ";" spring security web is throwing 500 response code with the full stack trace.
I think, for % and ; the same expectation we have as in response wise without exposing any bean or handle it explicitly.
i.e 400 Response code without a stack trace. Please let me know if you have any concern to reproduce this issue or with my explanation. Thank you.

[rwinch]

Thanks for the response. What is the stacktrace you see when providing % or ;? The screenshot you provided states for that scenario you are getting RequestRejectedException. If it is a RequestRejectedException then you can customize how it is handled with the changes for gh-5007 You can also test by trying out Spring Security 5.4.0-M1

[patelneelj]

@rwinch Yes. I can customize the workflow and can do something to handle especially for requestRejectedException.
But I believe, how, for "//" things was an issue before in #5007 and it was resolved in #7052 and now, we do not need to customize the workflow for "//".
The same way, I believe, the spring security should handle for ";" and "%" and the user should not require to customize for it by extending httpfirewall or something like that. With the latest spring version, you can easily reproduce this scenario. Please let me know if you have any concerns.

[rwinch]

Even after gh-7052 you need to customize the RequestRejectedHandler. Spring Security will process any request that is rejected using RequestRejectedHandler. This includes // ; and %. We will not change the default behaviour until the next major release. Please let me know if tehre are any additional changes you think that need to be made.

[patelneelj]

@rwinch That's the one I am explaining to you that we do not need to required to customize for// or /or \\
It is very well working as expected in spring security i.e no stack trace and 400 response code.

And I think, the same way, spring-security should behave for % and ;
However, currently it is not behaving the same way. For % and ; spring-security generated stack-trace and 500 response code which is totally different behavior then // or /or \\

[rwinch]

Thanks for your response. Some containers attempt to perform normalization for certain characters. For example, it might convert //foo//bar to /foo/bar before Spring Security even sees the URL. This might be why it appears that Spring Security is handling // differently.

Without a sample, I really cannot help you. The code always throws a RequestRejectedException if an invalid character is found and that RequestRejectedException is consistently handled with the RequestRejectedHandler. The default is to rethrow the RequestRejectedHandler which causes the default error handling to process it (typically this would be an internal server error).

I'm going to mark this as waiting for feedback again. If you need any further help, then I need a minimal and complete sample (i.e. link to a github repository that reproduces the issue) so I can reproduce/understand your problem.

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.