Handling of encoded slashes in paths

[dadrus]

Preflight checklist

• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines."
• I have discussed this feature request with the community.

Describe the background of your feature request

The actual FR comes from @netthier. The below is just copy&paste from his description in Discord. So, all credits to him ;)

Due to the ambiguous nature of URL-encoded slashes in paths (some applications parse it as path separators, others don't), I believe that one runs the risk of opening oneself up to Interpretation Conflict vulnerabilities when allowing them.

Apache 2 denies all such requests by default and recommends not decoding them if they are required, while nginx decodes them to path separators if the path was accessed at any point in the rule (e.g. to rewrite it), and doesn't otherwise. IIS treats them as path separators by default, as does Heimdall.

Heimdall possibly making a decision based on one interpretation of the URL while the backend uses another can be dangerous, and strictly speaking treating them as such goes against W3C Recommendations, see Example 2 on https://www.w3.org/Addressing/URL/4_URI_Recommentations.html.

However, I believe the current way Heimdall handles this when operating in proxy mode is safe, consequently treating encoded slashes and rewriting them to actual slashes when proxying to the backend. This property should be explicitly documented and tested for.

However, in decision mode this could quickly cause issues, as the backend could still receive encoded slashes and decide not to treat them as path separators.

Describe your idea

To ensure safe operation in decision mode, I see the following options:

1. Deny all requests with paths containing encoded slashes and hope that the actual proxy sends the same exact path to both services.
2. Return the request details as parsed by Heimdall as headers in the decision response, with proxies then being configured to always use that path. This could be applied to other URL components as well.
3. Return the rule ID together with a decision response and let the backend ensure that the correct rule was used.

IMO 2 would be the most robust, but is not something Heimdall can force. The examples in the docs would need to be updated to exclusively show that method for all integrations while warning against using the path the proxy understood.

I would also support making 1 the default in decision mode, with an explicit opt-out, like e.g. Apache does with AllowEncodedSlashes setting.

Are there any workarounds or alternatives?

Not really

Version

v0.11.1-alpha

Additional Context

Most users don't know how their specific proxy handles encoded slashes by default until it causes issues. As this feature is intended to stop 3rd parties trying to cause such issues, I think explicitly implementing a secure default in Heimdall is the way forward.

Heimdall offers a proxy mode where possibly no reverse proxy capable of doing such rewrites even is in front. If the backend decodes encoded slashes, Heimdall should also decode them. If the backend doesn't, Heimdall shouldn't either, and that needs to be configurable IMO.