WebFirewall falsifies method not allowed responses

[reitzmichnicht]

Describe the bug
With Spring Boot 3.4.3 and Spring Security 6.4.5
Testing a not annotated HTTP method against a Spring Rest Controller is expected to return a 405 http status, but instead returns 400 in some cases.

To Reproduce
Setup a RestController endpoint in spring and include spring security with default firewall settings. Then issue a TRACE request against the endpoint. (Trace is by default blocked by the spring security firewall settings)

Expected behavior
The spring web stack internally correctly generates a 405 response in this case, but the HttpStatusRequestRejectedHandler does map all those errors to a 400 bad request. While it could be argued that this is security by hiding details, this is not the case as the Allow header from the 405 response is still part of the bad request response. Our quickfix is to patch the HttpStatusRequestRejectedHandler to not overwrite 405 responses, but I do not know if this is the desired solution.

Sample
Can be provided on request.

[rwinch]

As you correctly pointed out, the firewall is intentionally responding with a 400. For your scenario you believe that a better status code is a 405, but if a request of TRACE /missing/resource is performed, then a status of 404 is likely more appropriate. Without traversing the logic of the web application to determine if the route is valid or not, the firewall cannot know what status is best. However, the point of the firewall is to prevent the traversal of the application logic with requests that have a high likelihood of being malicious to reduce the attack surface.

That said, you have two options:

1. If you are not concerned about XST (and similar attacks) and want to support TRACE, you can instruct the firewall to allow TRACE requests.
2. If you want to return a 405, then you can create custom error handling by exposing a RequestRejectedHandler as a Bean.

Please let me know if that resolves your concern.

[reitzmichnicht]

I agree to the your arguing and the design fact that the firewall should protect before business logic is executed. But in our analysis the framework web logic is already partly executed, because the RequestRejectedHandler already knows the difference between 404 and 405. So the knowledge is already there and then I think it doesn't make sense to violate http conventions for no reason.

And btw I do not want to enable TRACE stuff, we just test explicitly that it is disabled and those tests expect 405 return codes, thats why we investigated why the framework does not produce them.

[rwinch]

Some of the logic will always be invoked, but the key is to reduce that logic as much as possible. Figuring out a route is a lot more logic than figuring out a method.

If you want to always return a 405 for TRACE http method, then I'd suggest that you continue to use a custom HttpStatusRequestRejectedHandler.

Again, Spring Security will send a 405 status because it indicates that the resource exists, but the method is not supported for that resource. Spring Security cannot know if the route exists or not. Additionally, Spring Security does not know which methods are allowed on that particular resource to include in the Allow header.

In light of this, I'm closing the issue as invalid.